ETSITS 102 250-2 V1.5.1 



(2007-10) 



Technical Specification 



Speech Processing, Transmission and Quality Aspects (STQ); 

QoS aspects for popular services in GSM and 3G networks; 

Part 2: Definition of Quality of Service parameters 

and their computation 




ETSI TS 102 250-2 V1.5.1 (2007-10) 



Reference 



RTS/STQ-000119m 
Keywords 



3G, GSM, network, QoS, service, speech 



ETSI 

650 Route des Lucioles 
F-06921 Sophia Antipolis Cedex - FRANCE 

Tel. : +33 4 92 94 42 00 Fax: +33 4 93 65 47 1 6 

Siret N ° 348 623 562 0001 7 - NAF 742 C 
Association a but non lucratif enregistree a la 
Sous-Prefecture de Grasse (06) N° 7803/88 



Important notice 



Individual copies of the present document can be downloaded from: 
http://www.etsi.orq 

The present document may be made available in more than one electronic version or in print. In any case of existing or 

perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF). 

In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive 

within ETSI Secretariat. 

Users of the present document should be aware that the document may be subject to revision or change of status. 

Information on the current status of this and other ETSI documents is available at 

http://portal.etsi.org/tb/status/status.asp 

If you find errors in the present document, please send your comment to one of the following services: 

http://portal.etsi.orq/chaircor/ETSI support.asp 

Copyright Notification 

No part may be reproduced except as authorized by written permission. 
The copyright and the foregoing restriction extend to reproduction in all media. 

© European Telecommunications Standards Institute 2007. 
All rights reserved. 

DECT'^", PLUGTESTS™ and UMTS™ are Trade IVlarks of ETSI registered for the benefit of its IVIembers. 
TIPHON^" and the TIPHON logo are Trade Marks currently being registered by ETSI for the benefit of its Members. 
2QppTM |g g jracle Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners. 



ETSI 



ETSI TS 102 250-2 V1.5.1 (2007-10) 



Contents 



Intellectual Property Rights 16 

Foreword 16 

Introduction 17 

1 Scope 18 

2 References 18 

2.1 Normative references 19 

2.2 Informative references 20 

3 Definitions and abbreviations 20 

3.1 Definitions 20 

3.2 Abbreviations 22 

4 QoS Parameter Basics 24 

4.1 General Overview 24 

4.2 FTP, HTTP and E-Mail Issues 24 

4.2.1 Performance Enhancement Proxies 26 

5 Service independent QoS Parameters 27 

5.1 Radio Network Unavailability [%] 27 

5.1.1 Abstract Definition 27 

5.1.2 Abstract Equation 27 

5.1.3 Trigger Points 27 

5.2 Network Non- Accessibility [%] 28 

5.2.1 Abstract Definition 28 

5.2.2 Abstract Equation 28 

5.2.3 Trigger Points 28 

5.3 Attach Failure Ratio [%] 28 

5.3.1 Abstract Definition 28 

5.3.2 Abstract Equation 28 

5.3.3 Trigger Points 28 

5.4 Attach Setup Time [s] 29 

5.4.1 Abstract Definition 29 

5.4.2 Abstract Equation 29 

5.4.3 Trigger Points 30 

5.5 PDP Context Activation Failure Ratio [%] 30 

5.5.1 Abstract Definition 30 

5.5.2 Abstract Equation 30 

5.5.3 Trigger Points 30 

5.6 PDP Context Activation Time [s] 31 

5.6.1 Abstract Definition 31 

5.6.2 Abstract Equation 31 

5.6.3 Trigger Points 31 

5.7 PDP Context Cut-off Ratio [%] 32 

5.7.1 Abstract Definition 32 

5.7.2 Abstract Equation 32 

5.7.3 Trigger Points 32 

5.8 Data Call Access Failure Ratio [%] 32 

5.8.1 Abstract Definition 32 

5.8.2 Abstract Equation 32 

5.8.3 Trigger Points 32 

5.9 Data Call Access Time [s] 33 

5.9.1 Abstract Definition 33 

5.9.2 Abstract Equation 33 

5.9.3 Trigger Points 33 

5.10 DNS Host Name Resolution Failure Ratio [%] 34 

5.10.1 Abstract Definition 34 



£75/ 



5.10.2 


5.10.3 


5.11 


5.11.1 


5.11.2 


5.11.3 


6 


6.1 


6.1.1 


6.1.1.1 


6.1.1.2 


6.1.1.3 


6.1.2 


6.1.2.1 


6.1.2.2 


6.1.2.3 


6.1.3 


6.1.3.1 


6.1.3.2 


6.1.3.3 


6.1.4 


6.1.4.1 


6.1.4.2 


6.1.4.3 


6.1.5 


6.1.5.1 


6.1.5.2 


6.1.5.3 


6.1.6 


6.1.6.1 


6.1.6.2 


6.1.6.3 


6.1.7 


6.1.7.1 


6.1.7.2 


6.1.7.3 


6.1.8 


6.1.8.1 


6.1.8.2 


6.1.8.3 


6.2 


6.2.1 


6.2.1.1 


6.2.1.2 


6.2.1.3 


6.2.2 


6.2.2.1 


6.2.2.2 


6.2.2.3 


6.2.3 


6.2.3.1 


6.2.3.2 


6.2.3.3 


6.2.4 


6.2.4.1 


6.2.4.2 


6.2.4.3 


6.2.5 


6.2.5.1 


6.2.5.2 


6.2.5.3 



4 ETSI TS 1 02 250-2 V1 .5.1 (2007-1 0) 

Abstract Equation 34 

Trigger Points 34 

DNS Host Name Resolution Time [s] 34 

Abstract Definition 34 

Abstract Equation 35 

Trigger Points 35 

Direct Services QoS Parameters 35 

File Transfer (FTP) 35 

FTP {DownloadlUpload} Service Non- Accessibility [%] 35 

Abstract Definition 35 

Abstract Equation 35 

Trigger Points 36 

FTP {DownloadlUpload} Setup Time [s] 36 

Abstract Definition 36 

Abstract Equation 36 

Trigger Points 37 

FTP {DownloadlUpload} IP-Service Access Failure Ratio [%] 37 

Abstract Definition 37 

Abstract Equation 37 

Trigger Points 38 

FTP {DownloadlUpload} IP-Service Setup Time [s] 38 

Abstract Definition 38 

Abstract Equation 38 

Trigger Points 39 

FTP {DownloadlUpload} Session Failure Ratio [%] 39 

Abstract Definition 39 

Abstract Equation 39 

Trigger Points 39 

FTP {DownloadlUpload} Session Time [s] 40 

Abstract Definition 40 

Abstract Equation 40 

Trigger Points 40 

FTP {DownloadlUpload} Mean Data Rate [kbit/s] 40 

Abstract Definition 40 

Abstract Equation 41 

Trigger Points 41 

FTP {DownloadlUpload} Data Transfer Cut-off Ratio [%] 41 

Abstract Definition 41 

Abstract Equation 41 

Trigger Points 42 

Mobile Broadcast 42 

Mobile Broadcast Network Non-Availability {Broadcast Bearer} 44 

Abstract Definition 44 

Abstract Equation 44 

Trigger Points 44 

Mobile Broadcast Service Discovery Failure Ratio {Bootstrapping Bearer, ESG Retrieval Bearer} 44 

Abstract Definition 44 

Abstract Equation 45 

Trigger Points 45 

Mobile Broadcast Service Discovery Time {Bootstrapping Bearer, ESG Retrieval Bearer} 45 

Abstract Definition 45 

Abstract Equation 45 

Trigger Points 45 

Mobile Broadcast Bootstrapping Failure Ratio {Broadcast Bearer} 46 

Abstract Definition 46 

Abstract Equation 46 

Trigger Points 46 

Mobile Broadcast Bootstrapping Time {Broadcast Bearer} 46 

Abstract Definition 46 

Abstract Equation 46 

Trigger Points 46 



£75/ 



5 ETSI TS 1 02 250-2 V1 .5.1 (2007-1 0) 

6.2.6 Mobile Broadcast ESG Retrieval Failure Ratio {Bearer} 47 

6.2.6.1 Abstract Definition 47 

6.2.6.2 Abstract Equation 47 

6.2.6.3 Trigger Points 47 

6.2.7 Mobile Broadcast ESG Retrieval Time {Bearer} 47 

6.2.7.1 Abstract Definition 47 

6.2.7.2 Abstract Equation 47 

6.2.7.3 Trigger Points 48 

6.2.8 Mobile Broadcast Content Non-Accessibility {Broadcast Bearer} 48 

6.2.8.1 Abstract Definition 48 

6.2.8.2 Abstract Equation 48 

6.2.8.3 Trigger Points 48 

6.2.9 Mobile Broadcast Content Access Time {Broadcast Bearer} 49 

6.2.9.1 Abstract Definition 49 

6.2.9.2 Abstract Equation 49 

6.2.9.3 Trigger Points 49 

6.2.10 Mobile Broadcast Interactivity Response Failure Ratio {Mobile Network Bearer} {Broadcast 

Bearer} 49 

6.2.10.1 Abstract Definition 49 

6.2.10.2 Abstract Equation 49 

6.2.10.3 Trigger Points 50 

6.2.1 1 Mobile Broadcast Interactivity Response Time {Mobile Network Bearer} {Broadcast Bearer} 50 

6.2.11.1 Abstract Definition 50 

6.2.11.2 Abstract Equation 50 

6.2.11.3 Trigger Points 51 

6.2.12 Mobile Broadcast Service Integrity {Broadcast Bearer} 51 

6.3 Ping 52 

6.3.1 Ping Round Trip Time [ms] 52 

6.3.1.1 Abstract Definition 52 

6.3.1.2 Abstract Equation 52 

6.3.1.3 Trigger Points 52 

6.4 Push to Talk over Cellular (PoC) 53 

6.4.1 Definitions 53 

6.4.2 Generic Signal Flow 54 

6.4.3 PoC Registration Failure Ratio [%] 56 

6.4.3.1 Abstract Definition 56 

6.4.3.2 Abstract Equation 56 

6.4.3.3 Trigger Points 56 

6.4.4 PoC Registration Time [s] 57 

6.4.4.1 Abstract Definition 57 

6.4.4.2 Abstract Equation 57 

6.4.4.3 Trigger Points 57 

6.4.5 PoC Publish Failure Ratio [%] 58 

6.4.5.1 Abstract Definition 58 

6.4.5.2 Abstract Equation 58 

6.4.5.3 Trigger Points 58 

6.4.6 PoC Publish Time [s] 58 

6.4.6.1 Abstract Definition 58 

6.4.6.2 Abstract Equation 59 

6.4.6.3 Trigger Points 59 

6.4.7 PoC Registration Failure Ratio (long) [%] 59 

6.4.7.1 Abstract Definition 59 

6.4.7.2 Abstract Equation 59 

6.4.7.3 Trigger Points 60 

6.4.8 PoC Registration Time (long) [s] 60 

6.4.8.1 Abstract Definition 60 

6.4.8.2 Abstract Equation 60 

6.4.8.3 Trigger Points 61 

6.4.9 PoC Session Initiation Failure Ratio (on-demand) [%] 61 

6.4.9.1 Abstract Definition 61 

6.4.9.2 Abstract Equation 61 

6.4.9.3 Trigger Points 62 



£75/ 



6 ETSI TS 1 02 250-2 V1 .5.1 (2007-1 0) 

6.4.10 PoC Session Initiation Time (on-demand) [s] 62 

6.4.10.1 Abstract Definition 62 

6.4.10.2 Abstract Equation 63 

6.4.10.3 Trigger Points 63 

6.4.11 PoC Session Media Parameters Negotiation Failure Ratio (pre-established) [%] 64 

6.4.11.1 Abstract Definition 64 

6.4.11.2 Abstract Equation 64 

6.4.11.3 Trigger Points 64 

6.4.12 PoC Session Media Parameters Negotiation Time (pre-established) [s] 65 

6.4.12.1 Abstract Definition 65 

6.4.12.2 Abstract Equation 65 

6.4.12.3 Trigger Points 65 

6.4.13 PoC Session Initiation Failure Ratio (pre-established) [%] 66 

6.4.13.1 Abstract Definition 66 

6.4.13.2 Abstract Equation 66 

6.4.13.3 Trigger Points 67 

6.4.14 PoC Session Initiation Time (pre-established) [s] 67 

6.4.14.1 Abstract Definition 67 

6.4.14.2 Abstract Equation 67 

6.4.14.3 Trigger Points 68 

6.4.15 PoC Session Setup Failure Ratio (on-demand) [%] 68 

6.4.15.1 Abstract Definition 68 

6.4.15.2 Abstract Equation 69 

6.4.15.3 Trigger Points 69 

6.4.16 PoC Session Setup Failure Ratio (pre-established) [%] 69 

6.4.16.1 Abstract Definition 69 

6.4.16.2 Abstract Equation 70 

6.4.16.3 Trigger Points 70 

6.4.17 PoC Session Setup Time [s] 70 

6.4.17.1 Abstract Definition: 70 

6.4.17.2 Abstract Equation 70 

6.4.17.3 Trigger Points 71 

6.4.18 PoC Push to Speak Failure Ratio [%] 71 

6.4.18.1 Abstract Definition 71 

6.4.18.2 Abstract Equation 71 

6.4.18.3 Trigger Points 72 

6.4.19 PoC Push to Speak Time [s] 72 

6.4.19.1 Abstract Definition 72 

6.4.19.2 Abstract Equation 72 

6.4.19.3 Trigger Points 72 

6.4.20 PoC Session Leaving Failure Ratio (on-demand) [%] 73 

6.4.20.1 Abstract Definition 73 

6.4.20.2 Abstract Equation 73 

6.4.20.3 Trigger Points 73 

6.4.21 PoC Session Leaving Time (on-demand) [s] 73 

6.4.21.1 Abstract Definition 73 

6.4.21.2 Abstract Equation 74 

6.4.21.3 Trigger Points 74 

6.4.22 PoC Session Leaving Failure Ratio (pre-established) [%] 74 

6.4.22.1 Abstract Definition 74 

6.4.22.2 Abstract Equation 74 

6.4.22.3 Trigger Points 75 

6.4.23 PoC Session Leaving Time (pre-established) [s] 75 

6.4.23.1 Abstract Definition 75 

6.4.23.2 Abstract Equation 75 

6.4.23.3 Trigger Points 76 

6.4.24 PoC Deregistration Failure Ratio [%] 76 

6.4.24.1 Abstract Definition 76 

6.4.24.2 Abstract Equation 76 

6.4.24.3 Trigger Points 76 

6.4.25 PoC Deregistration Time [s] 77 

6.4.25.1 Abstract Definition 77 



£75/ 



7 ETSI TS 1 02 250-2 V1 .5.1 (2007-1 0) 

6.4.25.2 Abstract Equation 77 

6.4.25.3 Trigger Points 77 

6.4.26 PoC Busy Floor Response Failure Ratio [%] 77 

6.4.26.1 Abstract Definition 77 

6.4.26.2 Abstract Equation 78 

6.4.26.3 Trigger Points 78 

6.4.27 PoC Busy Floor Response Time [s] 78 

6.4.27.1 Abstract Definition 78 

6.4.27.2 Abstract Equation 78 

6.4.27.3 Trigger Points 79 

6.4.28 PoC Talk Burst Request Failure Ratio [%] 79 

6.4.28.1 Abstract Definition 79 

6.4.28.2 Abstract Equation 79 

6.4.28.3 Trigger Points 80 

6.4.29 PoC Talk Burst Request Time [s] 80 

6.4.29.1 Abstract Definition 80 

6.4.29.2 Abstract Equation 80 

6.4.29.3 Trigger Points 81 

6.4.30 PoC Talk Burst Cut-off Ratio [%] 81 

6.4.30.1 Abstract Definition 81 

6.4.30.2 Abstract Equation 81 

6.4.30.3 Trigger Points 82 

6.4.31 PoC Talk Burst Packet Drop Ratio [%] 82 

6.4.31.1 Abstract Definition 82 

6.4.31.2 Abstract Equation 82 

6.4.31.3 Trigger Points 83 

6.4.32 PoC Voice Transmission Delay (first) [s] 83 

6.4.32.1 Abstract Definition 83 

6.4.32.2 Abstract Equation 83 

6.4.32.3 Trigger Points 84 

6.4.33 PoC Voice Transmission Delay (others) [s] 84 

6.4.33.1 Abstract Definition 84 

6.4.33.2 Abstract Equation 85 

6.4.33.3 Trigger Points 85 

6.4.34 PoC Speech Quality 85 

6.4.35 Group Management QoS Parameter 85 

6.4.36 Group Document related QoS Parameter 85 

6.4.37 Instant Message QoS Parameter 85 

6.5 Streaming Video 85 

6.5.1 Definitions 85 

6.5.1.1 Streaming Session or Session 85 

6.5.2 Prerequisites 85 

6.5.3 Streaming Scenarios 86 

6.5.3.1 Generic Streaming Signalling Flow 86 

6.5.3.2 Parameter Overview Chart 87 

6.5.4 Streaming Service Non-Accessibility [%] 87 

6.5.4.1 Abstract Definition 87 

6.5.4.2 Abstract Equation 87 

6.5.4.3 Trigger Points 87 

6.5.5 Streaming Service Access Time [s] 88 

6.5.5.1 Abstract Definition 88 

6.5.5.2 Abstract Equation 88 

6.5.5.3 Trigger Points 88 

6.5.6 Streaming Reproduction Cut-off Ratio [%] 88 

6.5.6.1 Abstract Definition 88 

6.5.6.2 Abstract Equation 88 

6.5.6.3 Trigger Points 88 

6.5.7 Streaming Audio Quality 89 

6.5.7.1 Abstract Definition 89 

6.5.7.2 Abstract Equation 89 

6.5.7.3 Trigger Points 89 

6.5.8 Streaming Video Quality 89 



£75/ 



8 ETSI TS 1 02 250-2 V1 .5.1 (2007-1 0) 

6.5.8.1 Abstract Definition 89 

6.5.8.2 Abstract Equation 89 

6.5.8.3 Trigger Points 89 

6.5.9 Streaming Audio/Video De-Synchronization 90 

6.5.9.1 Abstract Definition 90 

6.5.9.2 Abstract Equation 90 

6.5.9.3 Trigger Points 90 

6.5.10 Streaming Reproduction Start Failure Ratio [%] 90 

6.5.10.1 Abstract Definition 90 

6.5.10.2 Abstract Equation 90 

6.5.10.3 Trigger Points 90 

6.5.11 Streaming Reproduction Start Delay [s] 91 

6.5.11.1 Abstract Definition 91 

6.5.11.2 Abstract Equation 91 

6.5.11.3 Trigger Points 91 

6.6 Telephony 91 

6.6.1 Telephony Service Non-Accessibility [%] 91 

6.6.1.1 Abstract Definition 91 

6.6.1.2 Abstract Equation 91 

6.6.1.3 Trigger Points 92 

6.6.2 Telephony Setup Time [s] 95 

6.6.2.1 Abstract Definition 95 

6.6.2.2 Abstract Equation 95 

6.6.2.3 Trigger Points 95 

6.6.3 Telephony Speech Quality on Call Basis 96 

6.6.3.1 Abstract Definition 96 

6.6.3.2 Abstract Equation 96 

6.6.3.3 Trigger Points 96 

6.6.4 Telephony Speech Quality on Sample Basis 96 

6.6.4.1 Abstract Definition 96 

6.6.4.2 Abstract Equation 96 

6.6.4.3 Trigger Points 97 

6.6.5 Telephony Cut-off Call Ratio [%] 97 

6.6.5.1 Abstract Definition 97 

6.6.5.2 Abstract Equation 97 

6.6.5.3 Trigger Points 97 

6.7 Video Telephony 97 

6.7.1 Network Accessibility/ Availability 97 

6.7.2 Parameter Overview Chart 98 

6.7.3 VT Service Non-Accessibility [%] 100 

6.7.3.1 Abstract Definition 100 

6.7.3.2 Abstract Equation 100 

6.7.3.3 Trigger Points 100 

6.7.4 VT Service Access Time [s] 101 

6.7.4.1 Abstract Definition 101 

6.7.4.2 Abstract Equation 101 

6.7.4.3 Trigger Points 101 

6.7.5 VT Audio/Video Setup Failure Ratio [%] 101 

6.7.5.1 Abstract Definition 101 

6.7.5.2 Abstract Equation 102 

6.7.5.3 Trigger Points 102 

6.7.6 VT Audio/Video Setup Time [s] 102 

6.7.6.1 Abstract Definition 102 

6.7.6.2 Abstract Equation 102 

6.7.6.3 Trigger Points 103 

6.7.7 VT Cut-off Call Ratio [%] 103 

6.7.7.1 Abstract Definition 103 

6.7.7.2 Abstract Equation 103 

6.7.7.3 Trigger Points 104 

6.7.8 VT Speech Quality on Call Basis [MOS-LQO] 105 

6.7.8.1 Abstract Definition 105 

6.7.8.2 Abstract Equation 105 



£75/ 



9 ETSI TS 1 02 250-2 V1 .5.1 (2007-1 0) 

6.7.8.3 Trigger Points 105 

6.7.9 VT Speech Quality on Sample Basis [MOS-LQO] 106 

6.7.9.1 Abstract Definition 106 

6.7.9.2 Abstract Equation 106 

6.7.9.3 Trigger Points 107 

6.7.10 VT Video Quality 107 

6.7.10.1 Abstract Definition 107 

6.7.10.2 Abstract Equation 107 

6.7.10.3 Trigger Points 108 

6.7.11 VT End-To-End Mean One-Way Transmission Time [s] 108 

6.7.11.1 Abstract Definition 108 

6.7.11.2 Abstract Equation 108 

6.7.11.3 Trigger Points 109 

6.7.12 VT Audio/Video Synchronization [%] 109 

6.7.12.1 Abstract Definition 109 

6.7.12.2 Abstract Equation 109 

6.7.12.3 Trigger Points 109 

6.7.13 Signalling Diagrams 110 

6.8 Web Browsing (HTTP) 113 

6.8.1 HTTP Service Non-Accessibility [%] 113 

6.8.1.1 Abstract Definition 113 

6.8.1.2 Abstract Equation 113 

6.8.1.3 Trigger Points 113 

6.8.2 HTTP Setup Time [s] 113 

6.8.2.1 Abstract Definition 113 

6.8.2.2 Abstract Equation 113 

6.8.2.3 Trigger Points 114 

6.8.3 HTTP IP-Service Access Failure Ratio [%] 114 

6.8.3.1 Abstract Definition 114 

6.8.3.2 Abstract Equation 114 

6.8.3.3 Trigger Points 114 

6.8.4 HTTP IP-Service Setup Time [s] 114 

6.8.4.1 Abstract Definition 114 

6.8.4.2 Abstract Equation 115 

6.8.4.3 Trigger Points 115 

6.8.5 HTTP Session Failure Ratio [%] 115 

6.8.5.1 Abstract Definition 115 

6.8.5.2 Abstract Equation 115 

6.8.5.3 Trigger Points 115 

6.8.6 HTTP Session Time [s] 115 

6.8.6.1 Abstract Definition 115 

6.8.6.2 Abstract Equation 115 

6.8.6.3 Trigger Points 116 

6.8.7 HTTP Mean Data Rate [kbit/s] 116 

6.8.7.1 Abstract Definition 116 

6.8.7.2 Abstract Equation 116 

6.8.7.3 Trigger Points 116 

6.8.8 HTTP Data Transfer Cut-off Ratio [%] 116 

6.8.8.1 Abstract Definition 116 

6.8.8.2 Abstract Equation 117 

6.8.8.3 Trigger Points 117 

6.9 Web Radio 117 

6.9.1 General 117 

6.9.2 Preconditions 117 

6.9.3 Special remarks on Internet radio audio playback and buffering 117 

6.9.4 Transaction Definition from Customer's perspective 118 

6.9.5 Resuh Definition 118 

6.9.6 KPl Overview 118 

6.9.7 Web Radio EPG Retrieval Failure Ratio [%] 118 

6.9.7.1 Abstract Definition 118 

6.9.7.2 Abstract Equation 119 

6.9.7.3 Trigger Points 119 



£75/ 



6.9.8 


6.9.8.1 


6.9.8.2 


6.9.8.3 


6.9.9 


6.9.9.1 


6.9.9.2 


6.9.9.3 


6.9.10 


6.9.10.1 


6.9.10.2 


6.9.10.3 


6.9.11 


6.9.11.1 


6.9.11.2 


6.9.11.3 


6.9.12 


6.9.12.1 


6.9.12.2 


6.9.12.3 


6.9.13 


6.9.13.1 


6.9.13.2 


6.9.13.3 


6.9.14 


6.10 


6.10.1 


6.10.2 


6.10.2.1 


6.10.2.2 


6.10.2.3 


6.10.3 


6.10.3.1 


6.10.3.2 


6.10.3.3 


6.10.4 


6.10.4.1 


6.10.4.2 


6.10.4.3 


6.10.5 


6.10.5.1 


6.10.5.2 


6.10.5.3 


6.10.6 


6.10.6.1 


6.10.6.2 


6.10.6.3 


6.10.7 


6.10.7.1 


6.10.7.2 


6.10.7.3 


6.10.8 


6.10.8.1 


6.10.8.2 


6.10.8.3 


6.10.9 


6.10.9.1 


6.10.9.2 


6.10.9.3 


6.10.10 


6.10.10.1 


6.10.10.2 



1 ETSI TS 1 02 250-2 V1 .5.1 (2007-1 0) 

Web Radio EPG Retrieval Time [s] 119 

Abstract Definition 119 

Abstract Equation 119 

Trigger Points 119 

Web Radio Tune-in Failure Ratio [%] 119 

Abstract Definition 119 

Abstract Equation 119 

Trigger Points 120 

Web Radio Tune-in Time [s] 120 

Abstract Definition 120 

Abstract Equation 120 

Trigger Points 120 

Web Radio Reproduction Set-up Failure Ratio [%] 120 

Abstract Definition 120 

Abstract Equation 120 

Trigger Points 121 

Web Radio Reproduction Set-Up Time [s] 121 

Abstract Definition 121 

Abstract Equation 121 

Trigger Points 121 

Web Radio Reproduction Cut-off Ratio [%] 121 

Abstract Definition 121 

Abstract Equation 122 

Trigger Points 122 

Web Radio Audio Quality 122 

WLAN service provisioning with HTTP based authentication 123 

Generic Signal Flow 123 

WLAN Scan Failure Ratio [%] 124 

Abstract Definition 124 

Abstract Equation 124 

Trigger Points 124 

WLAN Time to Scan [s] 124 

Abstract Definition 124 

Abstract Equation 125 

Trigger Points 125 

WLAN PS Data Service Provisioning Failure Ratio [%] 125 

Abstract Definition 125 

Abstract Equation 125 

Trigger Points 126 

WLAN PS Data Service Provisioning Time [s] 127 

Abstract Definition 127 

Abstract Equation 127 

Trigger Points 128 

WLAN Association Failure Ratio [%] 128 

Abstract Definition 128 

Abstract Equation 128 

Trigger Points 128 

WLAN Association Time [s] 129 

Abstract Definition 129 

Abstract Equation 129 

Trigger Points 129 

WLAN IP Address Allocation Failure Ratio [%] 129 

Abstract Definition 129 

Abstract Equation 129 

Trigger Points 130 

WLAN IP Address Allocation Time [s] 130 

Abstract Definition 130 

Abstract Equation 130 

Trigger Points 130 

WLAN Landing Page Download Failure Ratio [%] 130 

Abstract Definition 130 

Abstract Equation 130 



£75/ 



1 1 ETSI TS 1 02 250-2 V1 .5.1 (2007-1 0) 

6.10.10.3 Trigger Points 131 

6.10.11 WLAN Landing Page Download Time [s] 131 

6.10.11.1 Abstract Definition 131 

6.10.11.2 Abstract Equation 131 

6.10.11.3 Trigger Points 131 

6.10.12 WLAN Landing Page Password Retrieval Failure Ratio [%] 131 

6.10.12.1 Abstract Definition 131 

6.10.12.2 Abstract Equation 132 

6.10.12.3 Trigger Points 132 

6.10.13 WLAN Landing Page Password Retrieval Time [s] 132 

6.10.13.1 Abstract Definition 132 

6.10.13.2 Abstract Equation 132 

6.10.13.3 Trigger Points 132 

6.10.14 WLAN Landing Page Authorization Failure Ratio [%] 132 

6.10.14.1 Abstract Definition 132 

6.10.14.2 Abstract Equation 132 

6.10.14.3 Trigger Points 133 

6.10.15 WLAN Landing Page Authorization Time [s] 133 

6.10.15.1 Abstract Definition 133 

6.10.15.2 Abstract Equation 133 

6.10.15.3 Trigger Points 133 

6.10.16 WLAN Re-accessibility Failure Ratio [%] 133 

6.10.16.1 Abstract Definition 133 

6.10.16.2 Abstract Equation 134 

6.10.16.3 Trigger Points 134 

6.10.17 WLAN Re-accessibility Time [s] 134 

6.10.17.1 Abstract Definition 134 

6.10.17.2 Abstract Equation 134 

6.10.17.3 Trigger Points 135 

6.10.18 WLAN Logout Page Download Failure Ratio [%] 135 

6.10.18.1 Abstract Definition 135 

6.10.18.2 Abstract Equation 135 

6.10.18.3 Trigger Points 135 

6.10.19 WLAN Logout Page Download Time [s] 135 

6.10.19.1 Abstract Definition 135 

6.10.19.2 Abstract Equation 135 

6.10.19.3 Trigger Points 135 

6.11 Wireless Application Protocol (WAP) 136 

6.11.1 WAP Activation Failure Ratio [%] (WAP 1.x only) 137 

6.11.1.1 Abstract Definition 137 

6.11.1.2 Abstract Equation 137 

6.11.1.3 Trigger Points 137 

6.11.2 WAP Activation Time [s] (WAP 1.x only) 137 

6.11.2.1 Abstract Definition 137 

6.11.2.2 Abstract Equation 138 

6.11.2.3 Trigger Points 138 

6.11.3 WAP { Page} IP Access Failure Ratio [%] (WAP 2.x only) 138 

6.11.3.1 Abstract Definition 138 

6.11.3.2 Abstract Equation 138 

6.11.3.3 Trigger Points 138 

6.11.4 WAP {Page} IP Access Setup Time [s] (WAP 2.x only) 139 

6.11.4.1 Abstract Definition 139 

6.11.4.2 Abstract Equation 139 

6.11.4.3 Trigger Points 139 

6.11.5 WAP {Page} Session Failure Ratio [%] 139 

6.11.5.1 Abstract Definition 139 

6.11.5.2 Abstract Equation 139 

6.11.5.3 Trigger Points 140 

6.11.6 WAP {Page} Session Time [s] 140 

6.11.6.1 Abstract Definition 140 

6.11.6.2 Abstract Equation 140 

6.11.6.3 Trigger Points 140 



£75/ 



1 2 ETSI TS 1 02 250-2 V1 .5.1 (2007-1 0) 

6.11.7 WAP {Page} Request Failure Ratio [%] 141 

6.11.7.1 Abstract Definition 141 

6.11.7.2 Abstract Equation 141 

6.11.7.3 Trigger Points 141 

6.11.8 WAP {Page} Request Time [s] 141 

6.11.8.1 Abstract Definition 141 

6.11.8.2 Abstract Equation 141 

6.11.8.3 Trigger Points 141 

6.11.9 WAP {Page} Mean Data Rate [kbit/s] 142 

6.11.9.1 Abstract Definition 142 

6.11.9.2 Abstract Equation 142 

6.11.9.3 Trigger Points 142 

6.11.10 WAP {Page} Data Transfer Cut-off Ratio [%] 142 

6.11.10.1 Abstract Definition 142 

6.11.10.2 Abstract Equation 142 

6.11.10.3 Trigger Points 142 

6.11.11 WAP {Page} Data Transfer Time [s] 143 

6.11.11.1 Abstract Definition 143 

6.11.11.2 Abstract Equation 143 

6.11.11.3 Trigger Points 143 

7 Store-and-forward (S&F) Services QoS Parameters 143 

7.1 Generic Store-and-forward Parameters 144 

7.1.1 Parameter Overview Chart 144 

7.1.2 {Service} Message Upload Failure Ratio [%] 146 

7.1.2.1 Abstract Definition 146 

7.1.2.2 Abstract Equation 146 

7.1.2.3 Trigger Points 146 

7.1.3 {Service} Message Upload Time [s] 146 

7.1.3.1 Abstract Definition 146 

7.1.3.2 Abstract Equation 146 

7.1.3.3 Trigger Points 146 

7.1.4 {Service} Message Upload Access Failure Ratio [%] 146 

7.1.4.1 Abstract Definition 146 

7.1.4.2 Abstract Equation 146 

7.1.4.3 Trigger Points 147 

7.1.5 {Service} Message Upload Access Time [s] 147 

7.1.5.1 Abstract Definition 147 

7.1.5.2 Abstract Equation 147 

7.1.5.3 Trigger Points 147 

7.1.6 {Service} Message Upload Data Transfer Cut-off Ratio [%] 147 

7.1.6.1 Abstract Definition 147 

7.1.6.2 Abstract Equation 147 

7.1.6.3 Trigger Points 147 

7.1.7 {Service} Message Upload Data Transfer Time [s] 147 

7.1.7.1 Abstract Definition 147 

7.1.7.2 Abstract Equation 148 

7.1.7.3 Trigger Points 148 

7.1.8 {Service} Notification Start Failure Ratio [%] 148 

7.1.8.1 Abstract Definition 148 

7.1.8.2 Abstract Equation 148 

7.1.8.3 Trigger Points 148 

7.1.9 {Service} Notification Start Time [s] 148 

7.1.9.1 Abstract Definition 148 

7.1.9.2 Abstract Equation 148 

7.1.9.3 Trigger Points 148 

7.1.10 {Service} Notification Download Failure Ratio [%] 149 

7.1.10.1 Abstract Definition 149 

7.1.10.2 Abstract Equation 149 

7.1.10.3 Trigger Points 149 

7.1.11 {Service} Notification Download Time [s] 149 

7.1.11.1 Abstract Definition 149 



£75/ 



1 3 ETSI TS 1 02 250-2 V1 .5.1 (2007-1 0) 

7.1.11.2 Abstract Equation 149 

7.1.11.3 Trigger Points 149 

7.1.12 {Service} Notification Download Access Failure Ratio [%] 149 

7.1.12.1 Abstract Definition 149 

7.1.12.2 Abstract Equation 149 

7.1.12.3 Trigger Points 150 

7.1.13 {Service} Notification Download Access Time [s] 150 

7.1.13.1 Abstract Definition 150 

7.1.13.2 Abstract Equation 150 

7.1.13.3 Trigger Points 150 

7.1.14 {Service} Notification Data Transfer Cut-off Ratio [%] 150 

7.1.14.1 Abstract Definition 150 

7.1.14.2 Abstract Equation 150 

7.1.14.3 Trigger Points 150 

7.1.15 {Service} Notification Data Transfer Time [s] 150 

7.1.15.1 Abstract Definition 150 

7.1.15.2 Abstract Equation 151 

7.1.15.3 Trigger Points 151 

7.1.16 {Service} Message Download Failure Ratio [%] 151 

7.1.16.1 Abstract Definition 151 

7.1.16.2 Abstract Equation 151 

7.1.16.3 Trigger Points 151 

7.1.17 {Service} Message Download Time [s] 151 

7.1.17.1 Abstract Definition 151 

7.1.17.2 Abstract Equation 151 

7.1.17.3 Trigger Points 151 

7.1.18 {Service} Message Download Access Failure Ratio [%] 152 

7.1.18.1 Abstract Definition 152 

7.1.18.2 Abstract Equation 152 

7.1.18.3 Trigger Points 152 

7.1.19 {Service} Message Download Access Time [s] 152 

7.1.19.1 Abstract Definition 152 

7.1.19.2 Abstract Equation 152 

7.1.19.3 Trigger Points 152 

7.1.20 {Service} Message Download Data Transfer Cut-off Ratio [%] 152 

7.1.20.1 Abstract Definition 152 

7.1.20.2 Abstract Equation 152 

7.1.20.3 Trigger Points 153 

7.1.21 {Service} Message Download Data Transfer Time [s] 153 

7.1.21.1 Abstract Definition 153 

7.1.21.2 Abstract Equation 153 

7.1.21.3 Trigger Points 153 

7.1.22 {Service} Notification and Message Download Failure Ratio [%] 153 

7.1.22.1 Abstract Definition 153 

7.1.22.2 Abstract Equation 153 

7.1.22.3 Trigger Points 153 

7.1.23 {Service} Notification and Message Download Time [s] 153 

7.1.23.1 Abstract Definition 153 

7.1.23.2 Abstract Equation 154 

7.1.23.3 Trigger Points 154 

7.1.24 {Service} End-to-End Failure Ratio [%] 154 

7.1.24.1 Abstract Definition 154 

7.1.24.2 Abstract Equation 154 

7.1.24.3 Trigger Points 154 

7.1.25 {Service} End-to-End Time [s] 154 

7.1.25.1 Abstract Definition 154 

7.1.25.2 Abstract Equation 154 

7.1.25.3 Trigger Points 154 

7.2 E-Mail 155 

7.2.1 Parameter Overview Chart 155 

7.2.2 E-Mail {DownloadlUpload} Service Non- Accessibility [%] 155 

7.2.2.1 Abstract Definition 155 



£75/ 



1 4 ETSI TS 1 02 250-2 V1 .5.1 (2007-1 0) 

7.2.2.2 Abstract Equation 156 

7.2.2.3 Trigger Points 156 

7.2.3 E-Mail {DownloadlUpload} Setup Time [s] 156 

7.2.3.1 Abstract Definition 156 

7.2.3.2 Abstract Equation 156 

7.2.3.3 Trigger Points 157 

7.2.4 E-Mail {DownloadlUpload} IP-Service Access Failure Ratio [%] 157 

7.2.4.1 Abstract Definition 157 

7.2.4.2 Abstract Equation 157 

7.2.4.3 Trigger Points 158 

7.2.5 E-Mail {DownloadlUpload} IP-Service Setup Time [s] 158 

7.2.5.1 Abstract Definition 158 

7.2.5.2 Abstract Equation 158 

7.2.5.3 Trigger Points 159 

7.2.6 E-Mail {DownloadlUpload} Session Failure Ratio [%] 159 

7.2.6.1 Abstract Definition 159 

7.2.6.2 Abstract Equation 159 

7.2.6.3 Trigger Points 160 

7.2.7 E-Mail {DownloadlUpload} Session Time [s] 160 

7.2.7.1 Abstract Definition 160 

7.2.7.2 Abstract Equation 160 

7.2.7.3 Trigger Points 160 

7.2.8 E-Mail {DownloadlUpload} Mean Data Rate [kbit/s] 161 

7.2.8.1 Abstract Definition 161 

7.2.8.2 Abstract Equation 161 

7.2.8.3 Trigger Points 161 

7.2.9 E-Mail {DownloadlUpload} Data Transfer Cut-off Ratio [%] 162 

7.2.9.1 Abstract Definition 162 

7.2.9.2 Abstract Equation 162 

7.2.9.3 Trigger Points 162 

7.3 Multimedia Messaging Service (MMS) 163 

7.3.1 Parameter Overview Chart 164 

7.3.2 MMS Send Failure Ratio [%] 165 

7.3.2.1 Abstract Definition 165 

7.3.2.2 Abstract Equation 165 

7.3.2.3 Trigger Points 165 

7.3.3 MMS Retrieval Failure Ratio [%] 167 

7.3.3.1 Abstract Definition 167 

7.3.3.2 Abstract Equation 167 

7.3.3.3 Trigger Points 167 

7.3.4 MMS Send Time [s] 167 

7.3.4.1 Abstract Definition 167 

7.3.4.2 Abstract Equation 167 

7.3.4.3 Trigger Points 168 

7.3.5 MMS Retrieval Time [s] 168 

7.3.5.1 Abstract Definition 168 

7.3.5.2 Abstract Equation 168 

7.3.5.3 Trigger Points 168 

7.3.6 MMS Notification Failure Ratio [%] 169 

7.3.6.1 Abstract Definition 169 

7.3.6.2 Abstract Equation 169 

7.3.6.3 Trigger Points 169 

7.3.7 MMS Notification Time [s] 169 

7.3.7.1 Abstract Definition 169 

7.3.7.2 Abstract Equation 169 

7.3.7.3 Trigger Points 170 

7.3.8 MMS End-to-End Failure Ratio [%] 170 

7.3.8.1 Abstract Definition 170 

7.3.8.2 Abstract Equation 170 

7.3.8.3 Trigger Points 170 

7.3.9 MMS End-to-End Delivery Time [s] 171 

7.3.9.1 Abstract Definition 171 



£75/ 



1 5 ETSI TS 1 02 250-2 V1 .5.1 (2007-1 0) 

7.3.9.2 Abstract Equation 171 

7.3.9.3 Trigger Points 171 

7.4 Short Message Service (SMS) 172 

7.4.1 Parameter Overview Chart 172 

7.4.2 SMS Service Non-Accessibility MO [%] 173 

7.4.2.1 Abstract Definition 173 

7.4.2.2 Abstract Equation 173 

7.4.2.3 Trigger Points 173 

7.4.3 SMS Access Delay MO [s] 174 

7.4.3.1 Abstract Definition 174 

7.4.3.2 Abstract Equation 174 

7.4.3.3 Trigger Points 175 

7.4.4 SMS Completion Failure Ratio [%] 175 

7.4.4.1 Abstract Definition 175 

7.4.4.2 Abstract Equation 175 

7.4.4.3 Trigger Points 175 

7.4.5 SMS End-to-End Delivery Time [s] 176 

7.4.5.1 Abstract Definition 176 

7.4.5.2 Abstract Equation 176 

7.4.5.3 Trigger Points 176 

Annex A (informative): Examples for measuring trigger points 178 

Annex B (informative): Streaming explanations 179 

B.l Streaming Hyperlink Description 179 

Annex C (informative): Push to Talk over Cellular Information 180 

C.l Signal Grouping 184 

C.2 PoC Service Registration 185 

C.3 PoC Publish 185 

C.4 PoC Session Initiation, Originating Part 185 

C.5 PoC Session Initiation, Terminating Part 187 

C.6 Media Streaming 188 

C.7 Talk Burst Request 189 

C.8 Leaving PoC Session 189 

C.9 Deregistration 190 

Annex D (informative) : Bibliography 191 

History 192 



£75/ 



1 6 ETSI TS 1 02 250-2 V1 .5.1 (2007-1 0) 



Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by ETSI Technical Committee Speech Processing, Transmission 
and Quahty Aspects (STQ). 

The present document is part 2 of a multi-part deliverable covering the QoS aspects for popular services in GSM and 
3G networks, as identified below: 

Part 1 : "Identification of Quality of Service criteria"; 

Part 2: "Definition of Quality of Service parameters and their computation"; 

Part 3: "Typical procedures for Quality of Service measurement equipment"; 

Part 4: "Requirements for Quality of Service measurement equipment"; 

Part 5: "Definition of typical measurement profiles"; 

Part 6: "Post processing and statistical methods". 

Part 1 identifies QoS aspects for popular services in GSM and 3G networks. For each service chosen QoS indicators are 
listed. They are considered to be suitable for the quantitative characterization of the dominant technical QoS aspects as 
experienced from the end-customer perspective. 

Part 2 defines QoS parameters and their computation for popular services in GSM and 3G networks. The technical QoS 
indicators, listed in part 1, are the basis for the parameter set chosen. The parameter definition is split into three parts: 

• the abstract definition which contains a generic description of the parameter; 

• the abstract equation; and 

• the respective trigger points. 

Only measurement methods not dependent on any infrastructure provided are described in the present document. The 
harmonized definitions given in the present document are considered as the prerequisites for comparison of QoS 
measurements and measurement results. 

Part 3 describes typical procedures used for QoS measurements over GSM and 3G networks, along with settings and 
parameters for such measurements. 

Part 4 defines the minimum requirements of QoS measurement equipment for GSM and 3G networks in the way that 
the values and trigger points needed to compute the QoS parameter as defined in part 2 can be measured following the 
procedures defined in part 3. Test equipment fulfilling the specified minimum requirements will allow to perform the 
proposed measurements in a reliable and reproducible way. 

Part 5 specifies test profiles which are required to enable benchmarking of different GSM or 3G networks both within 
and outside national boundaries. These profiles are necessary for comparing "like-for-like" performance in case that a 
specific set of tests is carried out by different customers. 
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Part 6 describes procedures to be used for statistical calculations in the field of QoS measurement of GSM and 3G 
networks using probing systems. 



Introduction 

All the defined quality of service parameters and their computations are based on field measurements. This indicates 
that the measurements were made from customers point of view (full end-to-end perspective, taking into account the 
needs of testing). 

It is assumed that the end customer can handle his mobile and the services he wants to use (operability is not evaluated 
at this time). For the purpose of measurement it is assumed: 

• that the service is available and not barred for any reason; 

• routing is defined correctly without errors; and 

• the target subscriber equipment is ready to answer the call. 

Speech quality values from completed speech quality samples measured should only be employed by calls ended 
successfully for statistical analysis if the parameter speech quality per call is reported. 

However, measured values from calls ended unsuccessfully (e.g. dropped) should be available for additional evaluations 
(e.g. with the speech quality per sample parameter) and therefore must be stored. 

Further preconditions may apply when reasonable. 
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1 Scope 

The present document defines QoS parameters and their computation for popular services in GSM and 3G networks. 

The technical QoS indicators, listed in TS 102 250-1 [4], are the basis for the parameter set chosen. The parameter 
definition is split into three parts: 

• the abstract definition which contains a generic description of the parameter; 

• the abstract equation; and 

• the respective trigger points. 

Only measurement methods not dependent on any infrastructure provided are described in the present document. 

NOTE: Computation of certain parameters may vary depending on the respective cellular system, i.e. GSM or 
3GPP specified 3G system. In this case respective notification is provided. 

The harmonized definitions given in the present document are considered as the prerequisites for comparison of QoS 
measurements and measurement results. 

Other standardization bodies, namely the CBMS group in the DVB Forum and the BCAST group in OMA, requested an 
approved document for QoS parameters in Mobile Broadcast to be used as a reference in their documents. Therefore, 
the parameters described below should be approved even if technical trigger points still can not be defined in most of 
the cases. This is due to missing stable specifications in the mentioned bodies. If these specifications are available, the 
information will be added to enhance the parameter definitions given in the present document. 



References 



References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• Non-specific reference may be made only to a complete document or a part thereof and only in the following 

cases: 

if it is accepted that it will be possible to use all future changes of the referenced document for the purposes 
of the referring document; 

for informative references. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

For online referenced documents, information sufficient to identify and locate the source shall be provided. Preferably, 
the primary source of the referenced document should be cited, in order to ensure traceability. Furthermore, the 
reference should, as far as possible, remain valid for the expected life of the document. The reference shall include the 
method of access to the referenced document and the full network address, with the same punctuation and use of upper 
case and lower case letters. 

NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee 
their long term validity. 
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2.1 Normative references 

The following referenced documents are indispensable for the application of the present document. For dated 
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document 
(including any amendments) applies. 

[I] ITU-T Recommendation P.862: "Perceptual evaluation of speech quality (PESQ): An objective 
method for end-to-end speech quality assessment of narrowband telephone networks and speech 
codecs". 

[2] WAP-206-MMSCTR-20020115-a: "Wireless Application Protocol; Multimedia Messaging 

Service; Client Transactions Specification". 

[3] Void. 

[4] ETSI TS 102 250-1: "Speech Processing, Transmission and Quality Aspects (STQ); QoS aspects 

for popular services in GSM and 3G networks; Part 1 : Identification of Quality of Service aspects 
criteria". 

[5] ETSI TS 102 250-3: "Speech Processing, Transmission and Quality Aspects (STQ); QoS aspects 

for popular services in GSM and 3G networks; Part 3: Typical procedures for Quality of Service 
measurement equipment". 

[6] ITU-R Recommendation BS. 1387-1: "Method for objective measurements of perceived audio 

quality". 

[7] IETF RFC 3550 (2003): "RTP: A Transport Protocol for Real-Time Applications". 

[8] IETF RFC 2326 (1998): "Real Time Streaming Protocol (RTSP)". 

[9] ITU-T Recommendation P.862. 1 : "Mapping function for transforming P.862 raw result scores to 

MOS-LQO". 

[10] ETSI TS 124 008: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); Mobile radio interface Layer 3 specification; Core network 
protocols; Stage 3 (3GPP TS 24.008 Release 7)". 

[II] ETSI TS 145 008: "Digital cellular telecommunications system (Phase 2+); Radio subsystem link 
control (3GPP TS 45.008 Release 6)". 

[12] ETSI TS 129 002: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); Mobile Application Part (MAP) specification 
(3GPP TS 29.002 Release 6)". 

[13] ETSI TS 123 246: "Universal Mobile Telecommunications System (UMTS); Multimedia 

Broadcast/Multicast Service (MBMS); Architecture and functional description 
(3GPP TS 23.246 Release 6)". 

[14] Push to talk over Cellular (PoC) - Architecture, OMA approved Version 1.0. 

[15] Push to talk over Cellular (PoC) - User Plane, OMA approved Version 1.0. 

[16] Push to talk over Cellular (PoC) - Control Plane, OMA approved Version 1.0. 

[17] IETF RFC 3903: "Session Initiation Protocol (SIP) Extension for Event State Pubhcation". 

[18] ITU-T Recommendation P. 862.2: "Wideband extension to P.862 for the assessment of wideband 

telephone networks and speech codecs". 

[19] ITU-T Recommendation P. 862. 3: "Application guide for objective quality measurement based on 

Recommendations P.862, P862.1 and P.862.2". 

[20] ITU-T Recommendation E.800: "Terms and definitions related to quality of service and network 

performance including dependability". 
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[21] ETSI TS 127 007: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); AT command set for User Equipment (UE)". 

[22] ETSI TS 125 304: "Universal Mobile Telecommunications System (UMTS); User Equipment 

(UE) procedures in idle mode and procedures for cell reselection in connected mode". 

[23] ITU-T Recommendation P.800.1: "Mean Opinion Score (MOS) terminology". 

[24] ETSI TS 127 005: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); Use of Data Terminal Equipment - Data Circuit 
terminating Equipment (DTE-DCE) interface for Short Message Service (SMS) and Cell 
Broadcast Service (CBS)". 

2.2 Informative references 

[25] ETSI TS 102 250-5: "Speech Processing, Transmission and Quality Aspects (STQ); QoS aspects 

for popular services in GSM and 3G networks; Part 5: Definition of typical measurement profiles". 



Definitions and abbreviations 



3.1 Definitions 

For all QoS parameter definitions within the present document, the second column of the trigger point table - "Trigger 
Points" (from customer's point of view) - is mandatory (if present) for all QoS parameter definitions. In the case that the 
measurement system is capable of tracking details presented in the third column - "Technical Description" - the specific 
points indicated are also mandatory. 

For the purposes of the present document, the terms and definitions given in the ETSI Directives and the following 
apply: 

1-1 PoC session: feature enabling a PoC user to establish a PoC session with another PoC user 

ad-hoc PoC group session: PoC session for multiple PoC users that does not involve the use or definition of a 
pre-arranged or chat PoC group 

automatic answer: terminal accepts the invitation automatically if resources are available 

bearer: resource in the broadcast transport system that allows the transmission of data to the terminal or from the 
terminal 

NOTE: We distinguish between Broadcast Bearer and Mobile Network Bearer. The latter one is synonymously 
referred to as Interactivity Channel. 

bootstrapping: mechanism where the broadcast signal is accessed for the first time within a service usage 

NOTE: Parts of this procedure are the synchronization to the signal and its decoding so that afterwards a list of 
available channels is accessible and presented to the user. 

bootstrapping bearer: bearer on which the bootstrapping procedure is executed 

broadcast bearer: bearer supporting the broadcast service (e.g. DVB-H, MBMS, etc.) 

NOTE: The broadcast signal is transmitted via this bearer. 

chat PoC group: persistent group in which each member individually joins the PoC session i.e. the establishment of a 
PoC session to a chat PoC group does not result in other members of the chat PoC group being invited 

chat PoC group session: PoC session established to a chat PoC group 

confirmed indication: signalling message returned by the PoC server to confirm that the PoC server, all other network 
elements intermediary to the PoC server and a terminating terminal are able and willing to receive media 
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content: in case of a FTP session content is a file, in case of a HTTP session it is a web page and the content of an 
e-Mail session is the text of the e-Mail 

ESG retrieval bearer: bearer which is used to retrieve the ESG information 

last data packet: packet that is needed to complete the transmission of the content on the receiving side 

NOTE: For FTP download, the last data packet contains a set TCP FIN flag bit. 

manual answer: the PoC user accepts the invitation manually 

mobile broadcast service: end-to-end system for delivery of any types of digital content and services towards a mobile 
terminal using IP-based mechanisms 

mobile network bearer: bearer provided by a mobile network operator (e.g. GSM, GPRS, UMTS, etc.) to establish 
interactivity within the Mobile Broadcast Service 

on-demand session: PoC session set-up mechanism in which all media parameters are negotiated at PoC session 
establishment 

NOTE: The on-demand sessions are defined by the OMA PoC specification as mandatory for PoC enabled user 
equipment, whereas pre-established sessions are defined as optional. 

PoC session: established connection between PoC users where the users can communicate using voice one at a time 

PoC user: user of the PoC service 

pre-arranged PoC group session: persistent PoC session that has an associated set of PoC members 

NOTE: The establishment of a PoCsSession to a pre-arranged PoC group results in inviting all members of the 
defined group. 

pre-established session: SIP session established between the terminal and the PoC server that performs the 
participating PoC function 

NOTE: The terminal establishes the pre-established session prior to making requests for PoC sessions to other 
PoC users. 

service provider: operating company of a PLMN 

service user: end customer who uses the services of a PLMN by means of a UE, e.g. a mobile phone or data card 

talk burst: flow of media, e.g. some seconds of speech, from a terminal while that has the permission to send media 

talk burst control: control mechanism that arbitrates requests from the terminals, for the right to send media 

TBCP Talk Burst Granted: used by the PoC server to notify the terminal that it has been granted permission to send a 
talk burst 

NOTE: See [14] for possible floor states. 

TBCP Talk Burst Idle: used by the PoC server to notify all terminals that no one has the permission to send a talk 
burst at the moment and that it may accept the "TBCP Talk Burst Request" message 

NOTE: See [14] for possible floor states. 

TBCP Talk Burst Request: used by the terminal to request permission from the PoC server to send a talk burst 

NOTE: See [14] for possible floor states. 

terminal: shall be used when referring to a PoC enabled user equipment which is a user equipment implementing a PoC 
client 

NOTE: See [13]. 
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unconfirmed indication: indication returned by the PoC server to confirm that it is able to receive media and believes 
the terminal is able to accept media 

NOTE: The PoC server sends the unconfirmed indication prior to determining that all egress elements are ready 
or even able to receive media. 



3.2 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

3G 3'''1 Generation 

3GPP Third Generation Partnership Project 

AAL2 Asynchronous Transfer Mode Adaptation Layer type 2 

ACM Address Complete 

ALCAP Access Link Control Application Protocol 

AM Acknowledged Mode 

ANS ANSwer Message 

APN Access Point Name 

AT Command ATtention Command 

ATD ATtention Dial 

ATDT ATtention Dial Tone 

CCCH Common Control CHannel 

CRLF Carriage Return Line Feed 

CS Circuit Switched 

CUT PoC Session CUT-off (PoC) 

DCCH Dedicated Control CHannel 

DCE Data Circuit-terminating Equipment 

DCH Data CHannel 

DCH-FP Data CHannel Frame Protocol 

DELAY Talk Burst DELAY (PoC) 

DeREG PoC DeREGistration (PoC) 

DLDT DownLink Direct Transfer 

DNS Domain Name Service 

DP Detection Point 

DROP Talk Burst DROP (PoC) 

DT Direct Transfer 

DTE Data Terminal Equipment 

EPG Electronic Program Guide 

ESG Electronic Service Guide 

EACH Forward Access CHannel 

FTP File Transfer Protocol 

GGSN Gateway GPRS Support Node 

GMSC Gateway Mobile Switching Centre 

GPRS General Packet Radio Service 

GSM Global System for Mobile communications 

HLR Home Location Register 

HTTP HyperText Transfer Protocol 

lAM Initial Address Message 

ICMP Internet Control Message Protocol 

IMEI International Mobile Equipment Identification 

INIT PoC Session INITiation 

IP Internet Protocol 

ISUP ISDN User Part 

IWMSC Inter Working Mobile Switching Centre 

KPI Key Performance Indicator 

LI Layer 1 

L3 Layer 3 

LEAVE PoC Session LEAVing 

MB Mobile Broadcast 

MGW Media GateWay 

MMS Multimedia Messaging Service 
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MMSC Multimedia Messaging Service Centre 

MO Mobile Originated 

MOS Mean Opinion Score 

MOS-LQO Mean Opinion Score - Listening speech Quality Objective 

MS Mobile Station 

MSC Mobile Switching Centre 

MT Mobile Terminated 

NBAP Node B Application Part 

OMA Open Mobile Alliance 

PDF Packet Data Protocol 

PEP Performance Enhancement Proxy 

PLMN Public Land Mobile Network 

PoC Push to talk over Cellular 

POP3 Post Office Protocol version 3 

PS Packet Switched 

PtS Push to Speech 

PUB PoC PUBhsh 

QoS Quality of Service 

RAB Radio Access Bearer 

RACH Random Access CHannel 

RANAP Radio Access Network Application Protocol 

RAS Remote Access Service 

REG long PoC REGistration and Publish 

REG PoC REGistration 

REL Release Message 

RNC Radio Network Controller 

RRC Radio Resource Control 

RTCP Real Time Control Protocol 

RTP Real Time Protocol 

RTSP Real Time Streaming Protocol 

RX Reception 

SCCP Signalling Connection Control Part 

SDCCH Stand-alone Dedicated Control CHannel 

SDP Session Description Protocol 

SGSN Serving GPRS Support Node 

SIP Session Initiation Protocol 

SMS Short Message Service 

SMSC Short Message Service Centre 

SMTP Simple Mail Transfer Protocol 

SpQ Speech Quality 

SRTP Secure Real-time Transfer Protocol 

SYN TCP SYNchronize flag 

TBF Temporary Block Flow 

TCP Transmission Control Protocol 

TCP-HS Transmission Control Protocol HandShake 

TX Transmission 

UDP User Datagram Protocol 

UE User Equipment 

ULDT UpLink Direct Transfer 

UM Unacknowledged Mode 

UMTS Universal Mobile Telecommunications System 

VLR Visitor Location Register 

VT Video Telephony 

WAP Wireless Application Protocol 

WCDMA Wideband Code Division Multiple Access 

WGR WAP Get Request 

WSP Wireless Session Protocol 

WTP Wireless Transport Protocol 
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QoS Parameter Basics 



4.1 



General Overview 



Figure 1 shows a model for quality of service parameters. This model has four layers. 

The first layer is the Network Availability, which defines QoS rather from the viewpoint of the service provider than the 
service user. The second layer is the Network Access. From the service user's point of view this is the basic requirement 
for all the other QoS aspects and parameters. The third layer contains the other three QoS aspects Service Access, 
Service Integrity and Service Retainability. The different services are located in the fourth layer. Their outcome are the 
QoS parameters. 



r 
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Layer 1 



Network 
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Service 
Accessibility 
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switched 
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Figure 1 : QoS aspects and the corresponding QoS parameters 



4.2 



FTP, HTTP and E-Mail Issues 



Currently two main views about the best way to reflect the user's experience for these services are in place: One 
preferring the payload throughput philosophy and the other preferring the transaction throughput philosophy: 

• Method A defines trigger points which are as independent as possible from the service used, therefore 
representing a more generic view (payload throughput). 

• Method B defines trigger points on application layer, therefore representing a more service oriented view 
(transaction throughput). 
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An example of the different trigger points defined for each set is illustrated in figures 2 and 3: The start trigger point for 
the Mean Data Rate for Web browsing is either the reception of the first packet containing data content (Method A) or 
the sending of the HTTP GET command (Method B). 

A field test system compliant to the present document shall measure both sets (Method A and B) of QoS indicators 
using commercial UEs. 

In addition a set of technical QoS indicators is defined that covers the attach and PDP context activation procedure. 
Field test systems shall be able to measure these QoS indicators. 



User MS GPRS 

TCP/IP GPRS 



Server 




Figure 2: Key Performance Indicators Version A (Example: HTTP via GPRS) 
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GPRS 



Server 



Session ■/ 




Figure 3: Key Performance Indicators Version B (Example: HTTP via GPRS) 

4.2.1 Performance Enhancement Proxies 

Performance Enhancement Proxies (PEP, also called accelerators) are network elements employed to improve the 
performance of the data services offered by the mobile operator. To achieve this goal such proxies typically employ 
different techniques: 

• Content filtering (elimination of content of a certain type, e.g. audio files). 

• Lossless content compression (e.g. compression of HTML or other text like files). 

• Lossy content compression (e.g. recalculation of JPG files to a lower colour deepness or resolution of detail 
richness). 

• Protocol optimization (e.g. for HTTP, POP3). 

By these means PEPs achieve a reduction of the amount of data transferred from or to the end-user and thus a reduction 
of the transfer time. Some of these techniques will have an impact on content integrity and/or on the content quality as 
perceived by the end-user. 

The following guidelines apply whenever Performance Enhancement Proxies are employed: 

• When reporting mean data rates it shall be observed that the actual amount of transferred user data (rather than 
the original amount of hosted data) is used for calculations. 

• When reporting session times it is recommended that an indication of the impact of the enhancement 
techniques on the content quality is given - e.g. the content compression ratio (amount of received and 
uncompressed data divided by the amount of originally hosted data). 
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5 Service independent QoS Parameters 

5.1 Radio Network Unavailability [%] 



5.1.1 



Abstract Definition 



Probability that the mobile services are not offered to a user. 



5.1.2 Abstract Equation 



Radio Network Unavailability [%]- 



probing attempts with mobile services not available 
all probing attempts 



xlOO% 



5.1.3 Trigger Points 

GSM: 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical condition 


Probing attempt 


Not applicable. 


Check C1 -Criteria. 


Mobile services available 


Not applicable. 


GSM: CI -Criteria > 0. Any emergency camping 
on any other than the target networks is 
considered as no network. 


Mobile services not available 


Technical condition not met. 



GPRS: 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical condition 


Probing attempt 


Not applicable. 


Check GRPS specific signalling contained 
within System Information 3. 


Mobile service available 


Not applicable. 


Specific signalling contained in System 
Information 3 exists on cell selection. 


Mobile service not available 


Technical condition not met. 



UMTS (WCDMA): 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical condition 


Probing attempt 


Not applicable. 


Check S-Criteria. 


Mobile services available 


Not applicable. 


WCDMA: S-Criteria satisfied. Any emergency 
camping on any other than the target networks 
is considered as no network. 


Mobile services not available 


Technical condition not met. 



NOTE 1: For information on how the CI -criteria is defined please refer to TS 145 008 [11]. 

NOTE 2: For information on how the S -criteria is defined please refer to TS 125 304 [22]. 

NOTE 3: When the test mobile operates in dual-mode (GSM / UMTS) than the judgement on Radio Network 

Unavailability shall be made with respect to the radio access technology in which the test device is at the 
moment of the check. 

NOTE 4: The target networks could constitute of more than one network, e.g. to cover national or international 
roaming. 
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5.2 Network Non-Accessibility [%] 
5.2.1 Abstract Definition 

Probability that the user cannot perform a successful registration on the PLMN. 



5.2.2 Abstract Equation 



, ^^ . ^„, unsuccessfiil registrations on the PLMN , ^^ „ 

Network Non - Accessibility [%] = x 1 00 % 

all registration attempts 



5.2.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


Registration attempt 


Start: User turns UE on. 


Start: Not assignable. 


Successful registration 


Stop: Operator/PS logo appears in 
the display of the UE. 


Stop: 

"AT+CREG?" returns the value "1 " for <stat> 

(CS), 

"AT+CGREG?" returns the value "1" for <stat> 

(PS). 


Unsuccessful registration 


Stop trigger point not reached. 



NOTE 1: The AT command "AT+CREG?" will return the value "1" for <stat> if the UE is registered on the home 
network, both for GSM and UMTS, i.e. it cannot differentiate if the UE is registered to GSM or UMTS 
(see TS 127 007 [21]). Conform to this behaviour "AT+CGREG?" returns the value "1" for <stat> if the 
UE is registered either to GPRS or UMTS. 

NOTE 2: AT+CREG? and AT+CGREG? both return the access technology (<AcT>) selected by the UE when the 
unsolicited result code mode is enabled (<n>=2). In this case the value returned for <AcT> is "0" for 
GSM and "2" for UMTS. 



5.3 Attach Failure Ratio [%] 



5.3.1 Abstract Definition 

The attach failure ratio describes the probability that a subscriber cannot attach to the PS network. 



5.3.2 Abstract Equation 



, ^ ., „ . r^n unsuccessful attach attempts ,^^^ 

Attach Failure Ratio [%] = i— x 1 00 % 

all attach attempts 



5.3.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


Attach attempt 


Start: Customer turns the UE on. 


Start: UE sends the attach request message. 


Successful attach 


Stop: Attach logo appears in the 
display of the UE. 


Stop: UE receives the attach accept message. 


Unsuccessful attach 


Stop trigger point not reached. 
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Remarks: 



• The defined technical description / protocol part trigger points are on the lowest protocol layer. If this layer is 
not available, e.g. because the measurement equipment does not provide this layer, then upper protocol layer 
events can be used to measure the attach failure ratio. The chosen trigger points must be as close as possible to 
the lower layer events. The following example provides a possible solution. 

If the mobile fulfils TS 127 007 [21] then the following method (via AT interface) can be used for measuring 
the attach failure ratio: 

Start trigger: AT+CGATT = 1 ordered via the AT interface when the mobile is in detached state (use 
AT+CGATT? to check the state); 

Stop trigger: Any answer received from the mobile or timeout occurred. OK answer handled as a positive 
answer, any other as a negative one. 

• GPRS: Indicator will only be updated by event (a loss of SI13 signalling or a coverage hole will not be 
detected if no attach, routing area update or TBF request is initiated). 

• It might occur that the mobile station sends more than one attach request towards the SGSN, since retries are 
necessary. A maximum of four retries are possible (timer T3310 expires after 15 seconds for each attempt, 
see TS 124 008 [10]). Therefore the timeout interval for the attach procedure is 75 seconds, i.e. if the attach 
procedure was not completed after 75 seconds it is considered as failure. 

These retries should not have impact on the attach failure ratio, since only one attach request message should 
be counted in the calculation. 

• The PS bearer has to be active in the cell used by a subscriber (see clause 5.1). 

5.4 Attach Setup Time [s] 

5.4.1 Abstract Definition 

This attach setup time describes the time period needed to attach to the PS network. 

5.4.2 Abstract Equation 



Attach Setup Time [s] - \tg^g|,jj complete " '^attach request /[^] 



Remarks: 



The defined technical description / protocol part trigger points are on the lowest protocol layer. If this layer is 
not available, e.g. because the measurement equipment does not provide this layer, then upper protocol layer 
events can be used to measure the attach setup time. The chosen trigger points must be as close as possible to 
the lower layer events. The following example provides a possible solution. 

If the mobile fulfils TS 127 007 [21] then the following method (via AT interface) can be used for measuring 
the attach setup time: 

Start trigger: AT+CGATT = 1 ordered via the AT interface when the mobile is in detached state (use 
AT+CGATT? to check the state); 

Stop trigger: Any answer received from the mobile or timeout occurred. OK answer handled as a positive 
answer, any other as a negative one. If a positive answer is received the time period can be calculated. 

The difference between an attach of a known subscriber and an unknown subscriber will be reflected in the 
time period indicating the attach setup time. In case of an unknown subscriber (meaning that the SGSN has 
changed since the detach, or if it is the very first attach of the mobile to the network), the SGSN contacts the 
HLR in order to receive the subscriber data. The attach setup time of an unknown subscriber will be slightly 
longer than the one of a known subscriber. 
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• While determining the average attach setup time only successful attach attempts are included in the 
calculations. 

• The PS bearer has to be active in the cell used by a subscriber (see clause 5.1). 

5.4.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


^attach request '■ Time of attach 
request 


Start: Customer turns the UE on. 


Start: Point of time when the UE sends the 
attach request message. 


Uach complete : Time when attach 
complete 


Stop: Attach logo appears in the 
display of the UE. 


Stop: Point of time when the UE receives the 
attach accept message. 



5.5 PDP Context Activation Failure Ratio [%] 
5.5.1 Abstract Definition 

The PDP context activation failure ratio denotes the probability that the PDP context cannot be activated. It is the 
proportion of unsuccessful PDP context activation attempts and the total number of PDP context activation attempts. 



5.5.2 Abstract Equation 



PDP Context Activation Failure Ratio [%] 



unsuccessful PDP context activation attempts 
all PDP context activation attempts 



xlOO% 



5.5.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


Service access attempt 


Start: Customer Initiates the 
service access. 


Start: UE sends the first "Activate PDP context 
Request" message (Layer 3). 


Successful attempt 


Stop: PDP context logo appears in 
the display of the UE. 


Stop: UE receives the "Activate PDP context 
Accept" message (Layer 3). 


Unsuccessful attempt 


Stop trigger point not reached. 



Remarks: 



The defined technical description / protocol part trigger points are on the lowest protocol layer. If this layer is 
not available, e.g. because the measurement equipment does not provide this layer, then upper protocol layer 
events can be used to measure the PDP context activation failure ratio. The chosen trigger points must be as 
close as possible to the lower layer events. The following example provides a possible solution. 

If the mobile fulfils TS 127 007 [21] and if no authentification is needed to activate the PDP context then the 
following method (via AT interface) can be used for measuring the PDP context activation failure ratio: 

Start trigger: AT+CGACT =1,1 ordered via the AT interface when the mobile has no active context 
using the selected APN (use AT+CGACT? to check the state); 

Stop trigger: Any answer received from the mobile or timeout occurred. OK answer handled as a positive 
answer, any other as a negative one. If a positive answer is received the time period can be calculated. 

The PDP context should be defined with the AT+CGDCONT command. 
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• It might occur that the mobile station sends more than one PDP context activation request towards the SGSN, 
since retries are necessary. A maximum of four retries are possible (timer T3380 expires after 30 seconds for 
each attempt, see TS 124 008 [10]). Therefore the timeout interval for the PDP context activation procedure is 
150 seconds, i.e. if the PDP context activation procedure was not completed after 150 seconds it is considered 
as failure. 

• These retries should not have impact on the activation failure ratio, since only one PDP context activation 
request message should be counted in the calculation. 

• The PS bearer has to be active in the cell used by a subscriber (see clause 5.1) and the mobile station has to be 
attached (see clause 5.3). 

5.6 PDP Context Activation Time [s] 

5.6.1 Abstract Definition 

This parameter describes the time period needed for activating the PDP context. 

5.6.2 Abstract Equation 



PDP Context Activation Time [s] = (t 



PDP context activation accept " '•PDF context activation request 



t)[s] 



Remarks: 



The defined technical description / protocol part trigger points are on the lowest protocol layer. If this layer is 
not available, e.g. because the measurement equipment does not provide this layer, then upper protocol layer 
events can be used to measure the PDP context activation time. The chosen trigger points must be as close as 
possible to the lower layer events. The following example provides a possible solution. 

If the mobile fulfils TS 127 007 [21] and if no authentification is needed to activate the PDP context then the 
following method (via AT interface) can be used for measuring the PDP context activation time: 

Start trigger: AT+CGACT =1,1 ordered via the AT interface when the mobile has no active context 
using the selected APN (use AT+CGACT? to check the state); 

Stop trigger: Any answer received from the mobile or timeout occurred. OK answer handled as a positive 
answer, any other as a negative one. If a positive answer is received the time period can be calculated. 

The PDP context should be defined with the AT+CGDCONT command. 

While determining the average PDP context activation time only successful activation attempts are included in 
the calculations. 

The PDP context activation time should be determined per service, since the service might have impact on the 
actual activation time, e.g. different Access Point Names (APNs) for WAP. 

The PS bearer has to be active in the cell used by a subscriber (see clause 5.1) and the mobile station has to be 
attached (see clause 5.3). 



5.6.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


Vdp context activation request ■ Time 
of PDP context activation request 


Start: Customer initiates the 
service access. 


Start: Point of time when the UE sends the 
"Activate PDP context Request" message 
(Layer 3). 


^PDP context activation accept ■ Time 
when PDP context activation 
complete 


Stop: PDP context logo appears in 
the display of the UE. 


Stop: Point of time when the UE receives the 
"Activate PDP context Accept" message 
(Layer 3). 
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5.7 PDP Context Cut-off Ratio [%] 
5.7.1 Abstract Definition 

The PDP context cut-off ratio denotes the probability that a PDP context is deactivated without being initiated 
intentionally by the user. 



5.7.2 Abstract Equation 



PDP Context Cut - off Ratio [%] : 



PDP context losses not initiated by the user 
all successfully activated PDP contexts 



xlOO% 



5.7.3 Trigger Points 



Different trigger points for a PDP context deactivation not initiated intentionally by the user are possible: SGSN failure 
or GGSN failure on which the PDP context will be deactivated by the SGSN or GGSN. 

Remark: 

• Precondition for measuring this parameter is that a PDP context was successfully established first. 

5.8 Data Call Access Failure Ratio [%] 
5.8.1 Abstract Definition 

A subscriber (A-party) wants to take advantage of a given service offering (as shown by the network ID in the display 
of his user equipment) and establish a data call to a B-party. The failure of the data call access from initiating the data 
call to alerting or a busy signal is covered by this parameter. 



5.8.2 Abstract Equation 



Data Call Access Failure Ratio [%]- 



unsuccessHil data call accesses 
all data call access attempts 



xlOO% 



5.8.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


Data call access attempt 


Start: CONNECT button is 
pressed. 


Start: A CHANNEL_REQUEST message is sent 
over the RACH. 


Successful data call access 


Stop: Alert or busy signal occurs / 
connection established. 


Stop: Reception of CONNECT ACK at the 
A-party. 


Unsuccessful data call access 


Stop trigger point not reached. 



Remark: 



The defined technical description / protocol part trigger points are on the lowest protocol layer. If this layer is 
not available, e.g. because the measurement equipment does not provide this layer, then upper protocol layer 
events can be used to measure the data call access failure ratio. The chosen trigger points must be as close as 
possible to the lower layer events. The following example provides a possible solution. 
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If the mobile fulfils TS 127 007 [21] then the following method (via AT interface) can be used for measuring 
the data call access failure ratio: 

Start trigger: ATD + dial number (MSISDN) ordered via the AT interface when there is no ongoing call; 

Stop trigger: Any answer received from the mobile or timeout occurred. CONNECT answer handled as a 
positive answer, any other as a negative one. AT+CEER command can be used to read out the error 

cause. 

5.9 Data Call Access Time [s] 
5.9.1 Abstract Definition 

A subscriber (A-party) wants to take advantage of a given service offering (as shown by the network ID in the display 
of his user equipment) and establish a data call to a B-party. The time elapsing from initiating the data call to alerting or 
a busy signal is covered by this parameter. This parameter is not calculated unless the call attempt is successful and not 
cut off beforehand. 



5.9.2 Abstract Equation 



Data Call Access Time [s] = (t 



successful call access initiation of data call 



i)[s] 



5.9.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


^initiation of data call- ^ime of 
initiation of data call 


Start: Time at which CONNECT 
button is pressed. 


Start: A CHANNEL_REQUEST message is sent 
over the RACH. 


^Psuccessful call access- Time of 
successful data call access 


Stop: Time at which alert or busy 
signal occurs / connection 
established. 


Stop: Reception of CONNECT ACK at the 
A-party. 



Remark: 



The defined technical description / protocol part trigger points are on the lowest protocol layer. If this layer is 
not available, e.g. because the measurement equipment does not provide this layer, then upper protocol layer 
events can be used to measure the data call access time. The chosen trigger points must be as close as possible 
to the lower layer events. The following example provides a possible solution. 

If the mobile fulfils TS 127 007 [21] then the following method (via AT interface) can be used for measuring 
the data call access time: 

Start trigger: ATD + dial number (MSISDN) ordered via the AT interface when there is no ongoing call; 

Stop trigger: Any answer received from the mobile or timeout occurred. CONNECT answer handled as a 
positive answer, any other as a negative one. The AT+CEER command can be used to read out the error 
cause. If a positive answer is received the time period can be calculated. 
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5.10 DNS Host Name Resolution Failure Ratio [%] 
5.10.1 Abstract Definition 

The DNS host name resolution failure ratio is the probability that a host name to host address translation of a DNS 
resolver was not successful. 



Remarks: 



This QoS parameter is only relevant for packet switched services; 

resolutions of different host names shall not be compared directly, since the time to perform a search in the 
DNS server differs depending on the host name; 

resolutions involving different DNS name servers are not directly comparable; 

resolutions utilizing TCP can not be directly compared to resolutions using UDP, since messages carried by 
UDP are restricted to 512 bytes. UDP is the recommended method for standard queries on the Internet. 



5.10.2 Abstract Equation 



DNS Host Name Resolution Failure Ratio [%] = 

unsuccessful DNS host name resolution requests 
DNS host name resolution requests 



xlOO% 



5.10.3 Trigger Points 



Event from abstract 
equation 


Trigger point from 
customer's point of view 


Technical description / protocol part 


Host name resolution 
request 


Start: Request to resolve a 
host name. 


Start: Protocol: DNS. 

Data packet containing DNS type A (host address) "Standard 
query" message for the desired host name. 


Successful host name 
resolution request 


Stop: Host address resolved 
successfully. 


Stop: Protocol: DNS. 

Data packet received containing a type A (host address) 
"Standard query response, No error" response, the respective 
type A "Standard query" query and an answer including the 
desired host name to host address translation. 


Unsuccessful host name 
resolution request 


Stop: Host address not 
resolved. 


Stop trigger point not reached. 



Precondition for measurement: 

• The resolver shall not have direct access to any local DNS name server or any name server's zone. 

5.1 1 DNS Host Name Resolution Time [s] 
5.1 1 .1 Abstract Definition 

The DNS host name resolution time is the time it takes to perform a host name to host address translation. 
Remarks: 

• This QoS parameter is only relevant for packet switched services; 

• resolutions of different host names shall not be compared directly, since the time to perform a search in the 
DNS server differs depending on the host name; 
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• resolutions involving different DNS name servers are not directly comparable; 

• resolutions utilizing TCP can not be directly compared to resolutions using UDP, since messages carried by 
UDP are restricted to 512 bytes. UDP is the recommended method for standard queries on the Internet. 

5. 11 .2 Abstract Equation 



DNS Host Name Resolution Time [S] = (ts„ndardQueryRespon«= - tstandardQuery)[s] 



5.11.3 Trigger Points 



Event from abstract 
equation 


Trigger point from 
customer's point of view 


Tecfinical description / protocol part 


*StandardQuery ■ ^OSt name 

resolution request 


Start: Request to resolve a 
host address from DNS 
server. 


Start: Protocol: DNS. 

Data packet containing DNS type A (host address) 
"Standard query" query for the desired host name. 


'standardQueryResponse ■ "°^* 

name resolution request 
answered 


Stop: Host address 
received from DNS server. 


Stop: Protocol: DNS. 

Data packet received containing a type A (host address) 
"Standard query response, No error" response, the 
respective type A "Standard query" query and an answer 
including the desired host name to host address translation. 



Precondition for measurement: 

• The resolver shall not have direct access to any local DNS name server or any name server's zone. 

NOTE: For static measurement methodologies, as defined in TS 102 250-3 [5], the queried DNS name server 
shall have any data related to the host name to be resolved available as authoritative data in one of the 
name server's zones, so that no recursive lookups have to be performed and no use of cached information 
will be required. 

If the related data is not stored locally in the name server's zone, the resolution time would vary due to 
DNS caching strategies. 



6 Direct Services QoS Parameters 

6.1 File Transfer (FTP) 

6.1 .1 FTP {Download I Upload} Service Non-Accessibility [%] 
6.1.1.1 Abstract Definition 

The service accessibility ratio denotes the probability that a subscriber cannot establish a PDP context and access the 
service successfully. 



6.1.1.2 Abstract Equation 



FTP { Download I Upload} Service Non - Accessibility [%] = 

unsuccessful attempts to reach the point when content is sent or received 
all attempts to reach the point when content is sent or received 



xlOO% 
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6.1.1.3 Trigger Points 

Download: 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


Service access attempt 


Start: Customer initiates the 
service access. 


Start: AID command. 


Successful attempt 


Stop: File download starts. 


Stop IVIethod A: Reception of the first data 
packet containing content. 

Stop Method B: Reception of the [ACK] from the 
[SYN, ACK] for active mode connections, 
sending of the [ACK] for the [SYN, ACK] for 
passive mode connections on the data socket. 


Unsuccessful attempt 


Stop trigger point not reached. 



Upload: 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


Service access attempt 


Start: Customer initiates the 
service access. 


Start: AID command. 


Successful attempt 


Stop: File upload starts. 


Stop IVIethod A: Sending of the first data packet 
containing content. 

Stop IVIethod B: Reception of the [ACK] from the 
[SYN, ACK] for active mode connections, 
sending of the [ACK] for the [SYN, ACK] for 
passive mode connections on the data socket. 


Unsuccessful attempt 


Stop trigger point not reached. 



Remark: 

• The PS bearer has to be active in the cell used by a subscriber (see clause 5.1) and the mobile station has to be 
attached (see clause 5.3). 

6.1 .2 FTP {Download|Upload} Setup Time [s] 
6.1.2.1 Abstract Definition 

The setup time describes the time period needed to access the service successfully, from starting the dial-up connection 
to the point of time when the content is sent or received. 



6.1.2.2 Abstract Equation 



FTP {Download I Upload} Setup Time [s] = (t 



service access successful service access start 



t)[s] 
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6.1.2.3 Trigger Points 

Download: 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


Wrvice access start: Time of service 
access attempt 


Start: Customer initiates the 
service access. 


Start: AID command. 


^service access successful' "^® ° 
successful service access 


Stop: File download starts. 


Stop Method A: Reception of the first data 
packet containing content. 

Stop IVIethod B: Reception of the [ACK] from the 
[SYN, ACK] for active mode connections, 
sending of the [ACK] for the [SYN, ACK] for 
passive mode connections on the data socket. 



Upload: 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


^service access start: Time of service 
access attempt 


Start: Customer initiates the 
service access. 


Start: AID command. 


^service access successful' "^® ° 
successful service access 


Stop: File upload starts. 


Stop Method A: Sending of the first data packet 
containing content. 

Stop Method B: Reception of the [ACK] from the 
[SYN, ACK] for active mode connections, 
sending of the [ACK] for the [SYN, ACK] for 
passive mode connections on the data socket. 



Remark: 

• The PS bearer has to be active in the cell used by a subscriber (see clause 5.1) and the mobile station has to be 
attached (see clause 5.3). 

6.1 .3 FTP {Down load I Upload} IP-Service Access Failure Ratio [%] 
6.1.3.1 Abstract Definition 

The IP-service access ratio denotes the probability that a subscriber cannot establish an TCP/IP connection to the server 
of a service successfully. 



6.1.3.2 Abstract Equation 



FTP { Download I Upload} IP - Service Access Failure Ratio [%] = 

unsuccessful attempts to establish an IP connection to the server 
all attempts to establish an IP connection to the server 



xlOO% 
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6.1.3.3 Trigger Points 

Download: 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


IP-Service access attempt 


Start: Customer initiates file 
download. 


Start: First [SYN] sent on the data socket. 


Successful attempt 


Stop: File download starts. 


Stop Method A: Reception of the first data 
packet containing content. 

Stop IVIethod B: Reception of the [ACK] from the 
[SYN, ACK] for active mode connections, 
sending of the [ACK] for the [SYN, ACK] for 
passive mode connections on the data socket. 


Unsuccessful attempt 


Stop trigger point not reached. 



Upload: 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


IP-Service access attempt 


Start: Customer initiates file 
upload. 


Start: First [SYN] sent on the data socket. 


Successful attempt 


Stop: File upload starts. 


Stop IVIethod A: Sending of the first data packet 
containing content. 

Stop IVIethod B: Reception of the [ACK] from the 
[SYN, ACK] for active mode connections, 
sending of the [ACK] for the [SYN, ACK] for 
passive mode connections on the data socket. 


Unsuccessful attempt 


Stop trigger point not reached. 



Remark: 

• The PS bearer has to be active in the cell used by a subscriber (see clause 5.1) and the mobile station has to be 
attached (see clause 5.3) as well as the respective PDP context has to be activated (see clause 5.5). 

6.1 .4 FTP {Download|Upload} IP-Service Setup Time [s] 
6.1.4.1 Abstract Definition 

The IP-service setup time is the time period needed to establish an TCP/IP connection to the server of a service, from 
sending the initial query to a server to the point of time when the content is sent or received. 



6.1.4.2 Abstract Equation 



FTP {Download I Upload} IP - Service Setup Time [s] = (t 



IP-Service access successful IP-Service access start 



t)[s] 
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6.1.4.3 Trigger Points 

Download: 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


V-Service access start- Time of 
IP-Service access attempt 


Start: Customer initiates file 
download. 


Start: First [SYN] sent. 


V-Service access successful- Time Of 
successful IP-Service access 


Stop: File download starts. 


Stop Method A: Reception of the first data 
packet containing content. 

Stop IVIethod B: Reception of the [ACK] from the 
[SYN, ACK] for active mode connections, 
sending of the [ACK] for the [SYN, ACK] for 
passive mode connections on the data socket. 



Upload: 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


V-Service access start- Time of 
IP-Service access attempt 


Start: Customer initiates file 
upload. 


Start: First [SYN] sent. 


V-Service access successful- Time of 
successful IP-Service access 


Stop: File upload starts. 


Stop Method A: Sending of the first data packet 
containing content. 

Stop Method B: Reception of the [ACK] from the 
[SYN, ACK] for active mode connections, 
sending of the [ACK] for the [SYN, ACK] for 
passive mode connections on the data socket. 



Remark: 

• The PS bearer has to be active in the cell used by a subscriber (see clause 5.1) and the mobile station has to be 
attached (see clause 5.3) as well as the respective PDP context has to be activated (see clause 5.5). 

6.1 .5 FTP {Download|Upload} Session Failure Ratio [%] 
6.1.5.1 Abstract Definition 

The session failure ratio is the proportion of uncompleted sessions and sessions that were started successfully. 



6.1.5.2 Abstract Equation 



FTP {Download I Upload} Session Failure Ratio [%] : 



uncompleted sessions 
successfully started sessions 



-xlOO% 



6.1.5.3 Trigger Points 

Download: 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


Successfully started session 


Start: Customer initiates file 
download. 


Start: First [SYN] sent on the control socket. 


Completed session 


Stop: File download successfully 
completed. 


Stop: Reception of the last data packet 
containing content. 


Uncompleted session 


Stop trigger point not reached. 
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Upload: 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


Successfully started session 


Start: Customer initiates file 
upload. 


Start: First [SYN] sent on the control socket. 


Completed session 


Stop: File upload successfully 
completed. 


Stop: Reception of the [FIN, ACK] for the last 
data packet containing content. 


Uncompleted session 


Stop trigger point not reached. 



Remark: 

• The PS bearer has to be active in the cell used by a subscriber (see clause 5.1) and the mobile station has to be 
attached (see clause 5.3) as well as the respective PDP context has to be activated (see clause 5.5). 

6.1 .6 FTP {Download|Upload} Session Time [s] 
6.1.6.1 Abstract Definition 

The session time is the time period needed to successfully complete a PS data session. 



6.1.6.2 Abstract Equation 



FTP {Download I Upload} Session Time [s] = (t 



session end session start 



J[s] 



6.1.6.3 Trigger Points 

Download: 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


Wssion start: Time of successfully 
started session 


Start: Customer initiates file 
download. 


Start: First [SYN] sent on the control socket. 


Wssion end: Time when session 
completed 


Stop: File download successfully 
completed. 


Stop: Reception of the last data packet 
containing content. 



Upload: 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


Wssion start: Time of successfully 
started session 


Start: Customer initiates file 
upload. 


Start: First [SYN] sent on the control socket. 


Wssion end: Time when session 
completed 


Stop: File upload successfully 
completed. 


Stop: Reception of the [FIN, ACK] for the last 
data packet containing content. 



Remark: 

• The PS bearer has to be active in the cell used by a subscriber (see clause 5.1) and the mobile station has to be 
attached (see clause 5.3) as well as the respective PDP context has to be activated (see clause 5.5). 

6.1 .7 FTP {Download|Upload} Mean Data Rate [kbit/s] 
6.1.7.1 Abstract Definition 

After a data link has been successfully established, this parameter describes the average data transfer rate measured 
throughout the entire connect time to the service. The data transfer shall be successfully terminated. The prerequisite for 
this parameter is network and service access. 
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6.1.7.2 Abstract Equation 



FTP { Download I Upload } Mean Data Rate [kbit/s] = 



user data transferred [kbit] 



\ "'Hito l"t*in fTfii" i^/Trvrrxli^itd^ "^ n 



data transfer complete data transfer start 



)[S 



6.1.7.3 Trigger Points 

The average throughput is measured from opening the data connection to the end of the successftil transfer of the 
content (file). 

Download: 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


Wta transfer start : Time of 
successfully started data transfer 


Start: File download starts. 


Start Method A: Reception of the first data 
packet containing content. 

Start Method B: Reception of the [ACK] from the 
[SYN, ACK] for active mode connections, 
sending of the [ACK] for the [SYN, ACK] for 
passive mode connections on the data socket. 


Wta transfer complete : Time when 
data transfer complete 


Stop: File download successfully 
completed. 


Stop: Reception of the last data packet 
containing content. 



Upload: 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


Wta transfer start : Time of 
successfully started data transfer 


Start: File upload starts. 


Start Method A: Sending of the first data packet 
containing content. 

Start Method B: Reception of the [ACK] from the 
[SYN, ACK] for active mode connections; 
sending of the [ACK] for the [SYN, ACK] for 
passive mode connections on the data socket. 


Wta transfer complete : Time when 
data transfer complete 


Stop: File upload successfully 
completed. 


Stop: Reception of the [FIN, ACK] for the last 
data packet containing content. 



Remark: 

• The mobile station is already attached (see clause 5.3), a PDP context is activated (see clause 5.5) and a 
service was accessed successfully (see Service Non-Accessibility). 

6.1 .8 FTP {Download I Upload} Data Transfer Cut-off Ratio [%] 
6.1.8.1 Abstract Definition 

The data transfer cut-off ratio is the proportion of incomplete data transfers and data transfers that were started 
successfully. 



6.1.8.2 Abstract Equation 



FTP {Download I Upload} Data Transfer Cut - off Ratio [%] 
incomplete data transfers 



successfully started data transfers 



-xlOO% 
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6.1.8.3 Trigger Points 

Download: 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


Successfully started data transfer 


Start: File download starts. 


Start Method A: Reception of the first data 
packet containing content. 

Start Method B: Reception of the [ACK] from the 
[SYN, ACK] for active mode connections, 
sending of the [ACK] for the [SYN, ACK] for 
passive mode connections on the data socket. 


Complete data transfer 


Stop: File download successfully 
completed. 


Stop: Reception of the last data packet 
containing content. 


Incomplete data transfer 


Stop trigger point not reached. 



Upload: 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


Successfully started data transfer 


Start: File upload starts. 


Start Method A: Sending of the first data packet 
containing content. 

Start Method B: Reception of the [ACK] from the 
[SYN, ACK] for active mode connections, 
sending of the [ACK] for the[SYN, ACK] for 
passive mode connections on the data socket. 


Complete data transfer 


Stop: File upload successfully 
completed. 


Stop: Reception of the [FIN, ACK] for the last 
data packet containing content. 


Incomplete data transfer 


Stop trigger point not reached. 



Remark: 



6.2 



The mobile station is already attached (see clause 5.3), a PDP context is activated (see clause 5.5) and a 
service was accessed successfully (see Service Non-Accessibility). 

Mobile Broadcast 



Mobile Broadcast is an end-to-end broadcast system for delivery of any types of digital content and services using 
IP -based mechanisms. An inherent part of the Mobile Broadcast system is that it is comprised of an unidirectional 
broadcast path (e.g. DVB-H, MBMS, other broadcast bearers) and a bidirectional mobile/cellular interactivity path 
(e.g. GSM, GPRS, UMTS). The Mobile Broadcast Service is thus a platform for convergence of services from 
mobile/cellular and broadcast/media domains. 

Figure 4 depicts the basis for a generic service concept for mobile broadcast. As being a composite service, two 
different bearers may be involved in mobile broadcast services. Unidirectional broadcast information is transmitted over 
the broadcast channel, whereas interactive procedures are related to the interactivity channel provided by a mobile 
network. The independent procedures at both bearers may interact with each other and build a common end-to-end 
procedure. 

In general, this concept is not dedicated to specific bearer technologies. Different bearer technologies and their 
combinations are thinkable of 



Remark: 



However, the concept depends for example on the implementation of the Electronic Service Guide (ESG). If 
the ESG implementation does not allow the user to recognize the reception of ESG information, the according 
parameters shall have to be adapted. 
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Figure 4: Service phases of mobile broadcast 

From a customer's point of view, the usage cycle of mobile broadcast services can be divided into: 

• Terminal registrationLocal service activation: The broadcast receiver is switched on and the terminal registers 
to the broadcast bearer. This procedure includes the detection of a broadcast service signal. 

• Bootstrapping: During this phase, the detected broadcast signal is decoded. At the end of this phase, a list of 
receivables channels is available. Each channel offers additional information via its own Electronic Service 
Guide (ESG). 

• ESG Retrieval: At this stage, the information where to find ESG information is available. After a channel is 
selected, the channel related information is received, decoded and presented to the user. For example, an 
overview over the current and following programs can be shown on the display. The ESG information itself 
can be retrieved either via the broadcast bearer or via the interactivity service, for example via a WAP portal. 

• Service discovery: This phase includes the bootstrapping phase and the ESG retrieval phase. Please note that 
manual channel selection may lead to an additional delay between both phases. During this phase, the detected 
broadcast signal is decoded. Afterwards, the information where to find Electronic Service Guide (ESG) 
information is available. The ESG information itself can be retrieved either via the broadcast bearer or via the 
interactivity service, for example via a WAP portal. 

• Content reception: The generic term "content" comprises all kinds of content that can be transferred via the 
broadcast service. Examples for this kind of data are audio and video streams, file downloads and related 
metadata which describes the carried content. 

• Interactivity based procedures: These procedures allow the interactive use of the mobile broadcast service. In 
general, all transmission capabilities offered by the mobile network can be used for this issue. Examples are: 

content requests via a WAP GET request; 

SMS voting; 

request to receive ESG information via MMS service; or 

voice control to request a dedicated file via the broadcast service. 
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The technical interpretation of this generic usage cycle leads to the phases: 

• Mobile Broadcast Network Non- Accessibility. 

• Mobile Broadcast Service Discovery. 

• Mobile Broadcast Interactivity Response. 

• Mobile Broadcast Service Integrity. 

The mentioned phases are covered by the parameters described subsequently. 

6.2.1 Mobile Broadcast Network Non-Availability {Broadcast Bearer} 
6.2.1.1 Abstract Definition 

Probability that the Mobile Broadcast Services are not offered to an end-customer by the target network indicators on 
the User Equipment (UE) in idle mode. 



6.2.1.2 Abstract Equation 



Mobile Broadcast Network Non - Accessibility [%] = 

unsuccessful Mobile Broadcast registration attempts 
all Mobile Broadcast registration attempts 



xlOO% 



6.2.1.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


Mobile Broadcast registration 
attempt 


Start: Start of registration procedure 
performed by the UE. 


Tbd 


Unsuccessful IVIobile Broadcast 
registration attempt 


Stop: "IVIobile Broadcast icon", 
which indicates successfully 
registration, is not displayed on the 
UE. 


Tbd 



Preconditions for measurement: 

• The terminal shall be in an area which is intended to be covered by the broadcast service. 

• The receiver responsible for the reception of Mobile Broadcast services shall be activated and initialized. 

6.2.2 Mobile Broadcast Service Discovery Failure Ratio {Bootstrapping 
Bearer, ESG Retrieval Bearer} 

6.2.2.1 Abstract Definition 

Probability that the Mobile Broadcast Services are accessible by the user. The Service Discovery mechanism, 
responsible among others for proving the availability of services, plays a key role. The Service Discovery procedure can 
be divided in two phases: bootstrapping and ESG retrieval, which are dealt in following parameters and which may use 
different bearers. 



Remark: 



This parameter depends on the actual implementation of the service discovery procedures (e.g. use of cached 
bootstrapping and/or ESG information). 
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6.2.2.2 Abstract Equation 



Mobile Broadcast Service Discovery Failure Ratio [%] = 

unsuccessful Mobile Broadcast session start attempts 
all Mobile Broadcast session start attempts 



xlOO% 



6.2.2.3 Trigger Points 



Event from abstract 
equation 


Trigger point from 
customer's point of view 


Technical description / protocol part 


Mobile Broadcast session 
start / Service Discovery 
attempt 


Start: Request to use the 
Mobile Broadcast service 
on the 
UE. 


Start: DVB-H: Tbd 

MBMS: MBMS Broadcast Service Activation procedure 

(clause 8.12 of [13]). 


Unsuccessful Mobile 
Broadcast session start 
/Service Discovery 
attempt 


Stop: Mobile Broadcast 
service is not available on 
the UE. 


Tbd 



Preconditions for measurement: 

• Mobile Broadcast Network Availability must be given. 

6.2.3 Mobile Broadcast Service Discovery Time {Bootstrapping Bearer, 
ESG Retrieval Bearer} 

6.2.3.1 Abstract Definition 

The parameter Mobile Broadcast Initial Setup Time is the time period elapsed between a session start attempt of the 
Mobile Broadcast service and the available indication in the UE that grants access to the service. Hereby, the time the 
device requires to discover the available services for the first time is considered. 



6.2.3.2 Abstract Equation 



Mobile Broadcast Service Discoveiy Time [s] = (Imb session start " ^mb start attetnpt)[s] 



6.2.3.3 Trigger Points 



Event from abstract 
equation 


Trigger point from 
customer's point of view 


Technical description / protocol part 


Imb start attempt ■ Time of 
Mobile Broadcast 
session start / Service 
Discovery attempt 


Start: First request of the 
Mobile Broadcast service 
on the 
UE. 


Start: DVB-H: Tbd 

MBMS: MBMS Broadcast Service Activation procedure 

(clause 8.12 of [16]). Tbd 


tMB session start : Time of 
Mobile Broadcast 
session start 
/Successful Service 
Discovery 


Stop: Mobile Broadcast 
availability is given within a 
pre-determined time. 


Tbd 



Preconditions for measurement: 

• Mobile Broadcast Network Availability must be given. 
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6.2.4 Mobile Broadcast Bootstrapping Failure Ratio {Broadcast Bearer} 
6.2.4.1 Abstract Definition 

Probability that the first access to the broadcast signal fails. The failure may occur during synchronization to or 
decoding of the broadcast signal. 



6.2.4.2 Abstract Equation 



Mobile Broadcast Bootstrapping Failure Ratio [%] = 

unsuccessful bootstrapping procedures 
all Mobile Broadcast sesstion start / bootstrapping attempts 



-xlOO% 



6.2.4.3 Trigger Points 



Event from abstract 
equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


Mobile Broadcast session 
start / Bootstrapping 
attempt 


Start: Request to use the Mobile 
Broadcast service on the UE. 


Tbd 


Unsuccessful IVIobile 
Broadcast session start / 
Bootstrapping attempt 


Stop: May not be perceivable by the 
user. 


Tbd 



Preconditions for measurement: 

• Mobile Broadcast Network Availability must be given. 

6.2.5 Mobile Broadcast Bootstrapping Time {Broadcast Bearer} 
6.2.5.1 Abstract Definition 

The parameter Mobile Broadcast Bootstrapping Time measures the time it takes to perform the bootstrapping procedure 
consisting of the phases synchronization to the broadcast signal and broadcast signal decoding. 



6.2.5.2 Abstract Equation 



Mobile Broadcast Bootstrapping Time [S] = (tBootstrapping_end -tBootstrapping_start)[s] 



6.2.5.3 Trigger Points 



Event from abstract 
equation 


Trigger point from 
customer's point of view 


Technical description / protocol part 


*Bootstrapping_start ■ Time 
of Mobile Broadcast 
session start / 
bootstrapping attempt 


Start: Request to use the 
Mobile Broadcast service 
on the UE. 


Tbd 


*Bootstrapping_end ■ Time 

of successful Mobile 
Broadcast session start 
/ bootstrapping attempt 


Stop: May not be 
perceivable by the user. 


Tbd 



Preconditions for measurement: 

• Mobile Broadcast Bootstrapping procedure must be successful. 
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6.2.6 Mobile Broadcast ESG Retrieval Failure Ratio {Bearer} 
6.2.6.1 Abstract Definition 

Probability that the retrieval of ESG information fails. The acquisition and filtering of the Electronic Service Guide 
(ESG) information, as part of the Service Discovery mechanism, plays a key role. 



6.2.6.2 Abstract Equation 



Mobile Broadcast ESG Retrieval Failure Ratio [%] = 

unsuccessful reception of last ESG data packet 
reception of first ESG data packet 



xlOO% 



6.2.6.3 Trigger Points 



Event from abstract 
equation 


Trigger point from 
customer's point of view 


Technical description / protocol part 


Reception of first ESG 
data packet 


start: Indication of ESG 
retrieval. 


Tbd 


Unsuccessful reception of 
last ESG data packet 
needed to acquire a 
service 


Stop: IVIissing indication of 
termination of ESG 
retrieval. 


Tbd 



Preconditions for measurement: 

• For broadcast bearer: 

Mobile Broadcast Network Availability must be given. 
Mobile Broadcast Bootstrapping must be successful. 

• For mobile network bearer: 

Mobile Network Availability must be given. 

Mobile Network Service Accessibility for circuit switched or packet switched data services must be 
given. 

6.2.7 Mobile Broadcast ESG Retrieval Time {Bearer} 



6.2.7.1 



Abstract Definition 



The Mobile Broadcast ESG Retrieval Time is the time elapsed between the start of the ESG retrieval and the successful 
reception of the necessary ESG information required to acquire a service. The acquisition and filtering of the Electronic 
Service Guide (ESG) information, as part of the Service Discovery mechanism, plays a key role. 

6.2.7.2 Abstract Equation 



Mobile Broadcast ESG Retrieval Time [s] = (t 



ESGRetrievalTermination ESGRetrievalStart 



t)[s] 
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6.2.7.3 Trigger Points 



Event from abstract 
equation 


Trigger point from 
customer's point of view 


Technical description / protocol part 


'ESGRetrievalStart ■ ^ime 
of reception of first ESG 
data packet 


Start: Indication of ESG 
retrieval. 


Tbd 


^ESGRetrievalTermination ■ 
Time of reception of 
last ESG data pacl<et 
needed to acquire a 
service 


Stop: Indication of 
termination of ESG 
retrieval. 


Tbd 



Preconditions for measurement: 

• For broadcast bearer: 

Mobile Broadcast Network Availability must be given. 
Mobile Broadcast Bootstrapping must be successful. 

• For mobile network bearer: 

Mobile Network Availability must be given. 

Mobile Network Service Accessibility for circuit switched or packet switched data services must be 
given. 

ESG retrieval successfully started. 

6.2.8 Mobile Broadcast Content Non-Accessibility {Broadcast Bearer} 

6.2.8.1 Abstract Definition 

Probability that the requested Mobile Broadcast content (e.g. audio / video streaming data, files, metadata) is not started 
to be delivered to the user. This parameter applies also to zapping situations in which the customer changes the offered 
streaming content frequently in short intervals. 

6.2.8.2 Abstract Equation 



Mobile Broadcast Content Selection Non - Accessibility [%] 
unsuccessful receptions of first data packet 



all user's / client's content request attempts 



-xlOO% 



6.2.8.3 Trigger Points 



Event from abstract 
equation 


Trigger point from 
customer's point of view 


Technical description / protocol part 


User's /client's content 
request attempt 


Start: Request button 
pressed by user / request 
attempt from device. 


Start: Content Request on Interactivity Channel: Trigger 
points are chosen according to parameter definitions for 
SIVIS, MMS, GPRS and PS-UMTS in the present 
document.Tbd 


Unsuccessful reception of 
first content data packet 


Stop: IVIissing indication of 
reception of first content 
data packet. 


Stop: Content Request on Interactivity Channel: Trigger 
points are chosen according to parameter definitions for 
SIVIS, MMS, GPRS and PS-UMTS in the present 
document.Tbd 
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Preconditions for measurement: 

• Mobile Broadcast Network Availability must be given. 

• Mobile Broadcast Service Discovery must be successful. 

6.2.9 Mobile Broadcast Content Access Time {Broadcast Bearer} 
6.2.9.1 Abstract Definition 

The parameter Mobile Broadcast Content Access Time is the time period elapsed between the user's request to receive 
content and the reception of the first data packet. 



6.2.9.2 Abstract Equation 



Mobile Broadcast Content Access Time [S] = (tcontentDeliveryStart -tcontentRe^estAttempt)[s] 



6.2.9.3 Trigger Points 



Event from abstract 
equation 


Trigger point from 

customer's point of 

view 


Tecfinica! description / protocol part 


*ContentRequestAttempt- Time 

of user's/client's content 
request attempt 


Start: Request button 
pressed by user. 


Start: Content Request on Interactivity Channel: Trigger 
points are chosen according to parameter definitions for 
SIVIS, MMS, GPRS and PS-UIVITS in the present 
document. Tbd 


*ContentDeliveryStart- "'"''^^ °^ 
reception of first content 
data packet 


Stop: Indication of 
reception of first content 
data packet. 


Stop: Content Request on Interactivity Channel: Trigger 
points are chosen according to parameter definitions for 
SIVIS, MMS, GPRS and PS-UMTS in the present 
document. Tbd 



Preconditions for measurement: 

• Mobile Broadcast Network Availability must be given. 

• Mobile Broadcast Service Discovery must be successful. 

6.2.10 Mobile Broadcast Interactivity Response Failure Ratio {Mobile 
Network Bearer} {Broadcast Bearer} 

6.2.10.1 Abstract Definition 

The Mobile Broadcast Interactivity Response Failure Ratio measures the probability that a service request of a Mobile 
Broadcast service via an interactive channel does not result in an expected reaction (i.e. changes in content updated due 
to user's interaction, reception of any kind of notification to the user, etc.) on either the broadcast bearer or the mobile 
network bearer. 



6.2.10.2 Abstract Equation 



MobileBroadcastlnteractivity Response Failure Ratio [%] — 

unsuccessful Mobile Broadcastserviceoutcomes/ responses 
all Mobile Broadcastservice requests over interactive channel 



xlOO% 
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6.2.10.3 Trigger Points 



Event from abstract 
equation 


Trigger point from 
customer's point of view 


Teclinical description / protocol part 


Mobile Broadcast 
service request over 
the interactive channel 


Start: Request of the Mobile 
Broadcast service on the 
UE. 


Start: Content Request on Interactivity Channel: Trigger 
points are chosen according to parameter definitions for 
SMS, MMS, GPRS and PS-UMTS in the present 
document. Tbd 


Unsuccessful Mobile 
Broadcast service 
outcome/response 


Stop: User's interactivity is 
not reflected in updated 
content or indicated at the 
device. 


Stop: Tbd. Negative result code or timeout related to: 
Interactivity Channel: 

Trigger points are chosen according to parameter 
definitions for SMS, MMS, GPRS and PS-UMTS in the 
present document. 

Broadcast Bearer: 
DVB-H: Tbd 
MBMS: Tbd 



Preconditions for measurement: 

• For broadcast bearer: 

Mobile Broadcast Network Availability must be given. 
Mobile Broadcast Bootstrapping must be successful. 

• For mobile network bearer: 

Mobile Network Availability must be given. 

Mobile Network Service Accessibility for circuit switched or packet switched data services must be 
given. 

6.2.1 1 Mobile Broadcast Interactivity Response Time {Mobile Network 
Bearer} {Broadcast Bearer} 

6.2.1 1 .1 Abstract Definition 

The parameter Mobile Broadcast Interactivity Response Time is the time elapsed between a service request attempt of 
the Mobile Broadcast service via an interactive channel and the reception of a notification to the user. 



6.2.1 1 .2 Abstract Equation 



Mobile Broadcast Interactivity Response Time [s] = (tMBServiceResponse " tMBServiceRequest)[s] 
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6.2.11.3 Trigger Points 



Event from abstract 
equation 


Trigger point from 
customer's point of view 


Teclinical description / protocol part 


*MBServiceRequest ■ "'"''^^ 
of Mobile Broadcast 
service request over 
the interactive channel 


Start: Request of the IVIobile 
Broadcast service on the 
UE. 


Start: Content Request on Interactivity Channel: Trigger 
points are chosen according to parameter definitions for 
SMS, MMS, GPRS and PS-UMTS in the present 
document Tbd. 


'MBServiceResponse ■ 
Time of successful 
IVIobile Broadcast 
service outcome / 
response 


Stop: User's interactivity is 
not reflected in updated 
content or indicated at the 
device. 


Stop: Negative result code or timeout related to: 
Interactivity Channel: 

Trigger points are chosen according to parameter 
definitions for SMS, MMS, GPRS and PS-UMTS in the 
present document. 

Broadcast Bearer: 
DVB-H: Tbd 
MBMS: Tbd 



Preconditions for measurement: 

• For broadcast bearer: 

Mobile Broadcast Network Availability must be given. 
Mobile Broadcast Bootstrapping must be successful. 

• For mobile network bearer: 

Mobile Network Availability must be given. 

Mobile Network Service Accessibility for circuit switched or packet switched data services must be 
given. 

6.2.12 Mobile Broadcast Service Integrity {Broadcast Bearer} 

Mobile Broadcast technology paves the way for network operators and service providers to offer a huge palette of 
mobile services, which can be divided in the following categories: 

Streaming services. 

Packet switched data services. 

Short Message Service (SMS). 

Multimedia Message Service (MMS). 

Wireless Application Protocol (WAP). 

According to ITU-T Recommendation E.800 [20], the Service Integrity describes the Quality of Service during service 
use. Since the above mentioned services are already offered in other scenarios, in the present document only a reference 
to the already defined QoS parameters will be made. Important to bear in mind is the fact that for Mobile Broadcast 
Service, only the abstract definition of the parameters applies, since the underlying protocol stack may not be the same. 

The present document defines the following QoS parameters: 

• For packet switched data services: 

Completed Session Ratio. 
Mean Data Rate. 
Round Trip Time. 
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• For streaming services: 

Streaming Audio Quality. 
Streaming Video Quality. 
Streaming AudioA'^ideo De-Synchronization. 

• For short message services: 

End-to-end Delivery Time. 

• For multimedia message services: 

MMS Retrieval Failure Ratio (MT). 

MMS Send Time (MO). 

MMS Retrieval Time (MT). 

For wireless application protocol services, a reference from the Open Mobile Alliance (OMA) should be added (if 
available). 



6.3 



Ping 



6.3.1 Ping Round Trip Time [ms] 
6.3.1.1 Abstract Definition 

The round trip time is the time required for a packet to travel from a source to a destination and back. It is used to 
measure the delay on a network at a given time. For this measurement the service must already be established. 



6.3.1.2 Abstract Equation 



Ping Round Trip Time [ms] = (tp^.^et received " t packet sent )[ms] 



6.3.1.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


Vcket sent: Time when packet is 
sent 


Start: User starts Ping client. 


start: ICMP echo request sent. 


Vcket received: Time when packet 
is received 


Stop: Echo reply is displayed. 


Stop: ICMP echo reply received by the sender. 



As an alternative the measurement of the round trip time can done by evaluating the TCP handshake: 

• Start: Point of time when the [S YN] is sent. 

• Stop: Point of time when the [SYN, ACK] is received. 

This applies to all services that are TCP based, e.g. file transfer (FTP), web browsing (HTTP) and E-Mail (POP3, 
SMTP). 
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6.4 Push to Talk over Cellular (PoC) 

The present clause describes QoS parameters for the Push to Talk over Cellular (PoC) service as described in [14], [15], 
[16] and [17]. 

To point out the development and effectiveness of these QoS parameters, a generic PoC signal flow is given. Here, 
some restricted information on the application layer is given. These events only show important user interactions. In this 
context it is important to point out that the present document does not focus on the application layer or the user plane as 
described in [15]. 

The SDP is not mentioned as an alternative to RTP in [14], [15] and [16]. Thus, trigger points defined on the SDP layer 
are out of scope of the present document. 

NOTE: All Quality of Service parameters defined for the PoC service which do not rely on RTP in terms of 
trigger point definition are to be applied when measuring a PoC service utilizing SRTP. 

Furthermore, some typical PoC signal flows are given in an informative annex together with some signal grouping. 
Here, signals have been grouped together in order the give a better insight into the signal flow details and their relation 
to some specific group of PoC QoS parameters. 

The Push to Talk over Cellular (PoC) service is characterized by a half duplex form of communication, whereby one 
end-user will communicate with other end-users by pressing a button, or an equivalent function, on a terminal. In the 
following text it will be assumed without loss of generality that the terminal has a PoC button. 

It is important to keep in mind that measurement equipment and techniques used can affect the data collected. The 
measurement equipment and techniques should be defined and their effects documented for all tests. 

Remarks: 

• All end trigger points defined in the present document will occur after the appropriate start trigger points. The 
message flow between each two trigger points is described in the text or there is a reference to a figure that 
visualizes the message flow. 

• All SIP and RTP messages that are sent during a PoC session utilize UDP as transport layer. 

• If a trigger point (technical description / protocol part) in the present document states: "First data packet 
sent. . ." then the time stamp shall be the point in time when the message is posted to the UDP transport layer. 

• If a trigger point (technical description / protocol part) in the present document states: "First data packet 
received. . ." then the time stamp shall be the point in time when the message is received on the UDP transport 
layer. 

• Trigger points for failure ratios (technical description / protocol part) may state: "No message received by the 
terminal within a pre-determined time", which means that the PoC server timed out. Here, the exact timeout 
has to be specified. 

• If the present document states: "active PoC talk session", then a PoC session with at least two joining parties is 
meant, regardless of the kind of session (1-1, ad-hoc group talk, pre-arranged group talk or chat). Furthermore, 
one of the participating terminals shall create and send data packets containing speech data (RTP media 
stream). 

• Unless explicitly stated differently, all terminals participating in PoC sessions shall not generate notification 
messages. Otherwise, "SIP NOTIFY" messages might get sent to these clients leading to possible impacts on 
the measurement results. 

6.4.1 Definitions 

For PoC, there are differences between on-demand and pre-established PoC sessions which need to be taken into 
account. Thus, a direct comparison between these session types shall be avoided. 

Another difference to be aware of is the form of indication used. If confirmed indication is used, the initiator has to wait 
for the "talk burst granted" indication until at least one invited user has accepted the invitation. If unconfirmed 
indication is used, at least one invited user has to be registered and uses automatic answer. This results in different 
message flows as well as in different response times (especially if media buffering is supported by the PoC server). 
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Particularities occur when using a pre-arranged PoC group session. In this kind of session the initiator invites a group of 
users. With confirmed indication at least one user has to accept the invitation but with unconfirmed indication the 
right-to-speak is granted at once; regardless if a user of the group is connected to the PoC service or not. 

Table 1 gives an overview of the defined QoS parameters. Groups of parameters are introduced to visualize 
interdependencies. The reason is that certain measurements can only take place if several preconditions are fulfilled. 

Table 1 : QoS parameter and required preconditions 



QoS Group 


Description 


QoS parameter in this group 


Preconditions 


REG 


PoC Registration 


6.4.3, 6.4.4 


- 


PUB 


PoC Publish 


6.4.5, 6.4.6 


REG 


REG long 


PoC Registration + PoC Publish 


6.4.6.3, 6.4.7.3 


- 


■D 

re 

O T3 


INIT 


PoC Session Initiation 


6.4.8.3,6.4.9.3 


PUB 


SETUP 


PoC Session Setup 


6.4.14.3,6.4.17 


- 


PtS 


Push to Speech 


6.4.18, 6.4.19 


PUB 


LEAVE 


PoC Session Leaving 


6.4.20, 6.4.21 


INIT or SETUP 


!5 

CO 
0) 

^^ 
Q. 0} 


NEGO 


PoC IVIedia Parameters Negotiation 


6.4.10.3, 6.4.11.3 


PUB 


INIT 


PoC Session Initiation 


6.4.12.3,6.4.14 


NEGO 


SETUP 


PoC Session Setup 


6.4.16, 6.4.17 


- 


PtS 


Push to Speech 


6.4.18, 6.4.19 


PUB 


LEAVE 


PoC Session Leaving 


6.4.22, 6.4.23 


INIT or SETUP 


DeREG 


PoC Deregistration 


6.4.24, 6.4.25 


REG or SETUP 


BUSY 


Busy Floor Response 


6.4.26, 6.4.27 


SETUP or PtS 


REQ 


Talk Burst Request 


6.4.28, 6.4.29 


SETUP or PtS 


CUT 


PoC Session Cut-off 


6.4.30 


SETUP or PtS 


DROP 


Talk Burst Drop 


6.4.31 


SETUP or PtS 


DELAY 


Talk Burst Delay 


6.4.32, 6.4.33 


SETUO or PtS 



6.4.2 Generic Signal Flow 



This clause gives an overview of some signal flows evolving from PoC sessions. In figure 5, a generic signal flow is 
given. Here, the main parts of a PoC session, also including the registration of the PoC service, are visualized. These 
are: PoC service registration (including PoC service settings publishment), PoC session initiation, PoC talk session, PoC 
session leaving and finally the PoC service deregistration. 

Most of the PoC relevant (application layer-) events generated from or receivable by the user are included in this figure. 
These events are represented as dashed lines. 

In the present document greyed lines are optional signals which do not have to be send (like the "SIP NOTIFY" 
message which will only be send by the PoC server if the "norefersub" option tag was included in the "SIP REFER" 
request (see [16])). Provisional SIP responses as described in [6] (e.g. "SIP 100 Trying") are greyed for clarity. These 
messages are provisional responses and shall be turned off during measurements. 
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A generic PoC session: 
I I PoC Registration. 

^^^B PoC Session Initiation. 
^^^H PoC Talk Session. 
^^^^ Leaving PoC Session. 
^^^H PoC Deregistration. 



Tenninal A 



User APoC Service 
Registration 



PoC Networic 



Registration 



"PoC active" indicated 



Talk Burst Request 
(Pushing PoC but on) 



Terminal B 



Registration 



4 



User B PoC Service 
Registration 




"PoC active" indicated 



User B accepts incoming 
PoC session 



End of speech 



Talk Burst Request 
(PushingPoC button) 



^t_ait ofjgeech 



User B Service 
Deregistration 



"PoC inactive" indicated 



NOTE: Here, the dashed arrows indicate events generated from or receivable by the user. 

Figure 5: Generic PoC session signal flow 
(including PoC service registration) on application layer. 
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6.4.3 PoC Registration Failure Ratio [%] 
6.4.3.1 Abstract Definition 

The PoC registration failure ratio is the probability that the terminal can not register with the Push to Talk over Cellular 
service when requested. 



Remark: 



The terminal shall not be registered to the PoC service. 



6.4.3.2 Abstract Equation 



^ „„ . . ^ ., T^ . r^n unsuccessful PoC registration attempts ,„„^ 

PoC Registration Failure Ratio [%] = i— x 100 % 

all PoC registration attempts 



Terminal 



SIP REGISTER 



SIP 401 Unauthorized 



SIP REGISTER 



SIP 403 Forbidden 



SIP Core 



NOTE: Figure 6 shows an example for an unsuccessful PoC registration. After the first "SIP REGISTER" request 
the terminal has to answer to a WWW- authentication challenge (see [1 6]). If the terminal does not answer 
correctly to this challenge, the SIP core will send a "SIP 403 Forbidden" message. 



Figure 6: Unsuccessful PoC registration example 



6.4.3.3 Trigger Points 



Event from abstract 
equation 


Trigger point from 
customer's point of view 


Technical description / protocol part 


PoC registration attempt 


Start: Activation of the PoC 
service on the terminal. 


Start: Protocol: SIP. 

First data packet sent by the terminal containing a "SIP 
REGISTER" message. 


Successful PoC 
registration attempt 


Stop: PoC available is 
indicated. 


Stop: Protocol: SIP. 

First data packet received containing a "SIP 200 OK" 
message. 


Unsuccessful PoC 
registration attempt 


Stop: PoC available 
indication is not given within 
a pre-determined time. 


Stop: Protocol: SIP. 

Case 1 : Second data packet received by the terminal (after 
sending the "SIP REGISTER" message) containing a 
message different to "SIP 200 OK". This message may be 
implementation-dependent (see [16]). 

Case 2: First data packet received by the terminal (after the 
authentication procedure) containing a message different to 
"SIP 200 OK". 

Case 3: No message received by the terminal within a 
pre-determined time. 
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6.4.4 PoC Registration Time [s] 
6.4.4.1 Abstract Definition 

The PoC registration time is the time period between the registration request of the PoC service and being registered to 
the PoC service. 



Remark: 



The terminal shall not be registered to the PoC service. 



6.4.4.2 Abstract Equation 



PoC Registration Time [s] = (t 



PoCAvailable ^ PoCActivated 



,)[s] 



Terminal 



SIP Core 



SIP REGISTER 



SIP 401 Unauthorized 



SIP REGISTER 



SIP 200 OK 



NOTE: Figure 7 shows an example of a successful PoC registration (see [1 6]). In contrast to figure 1 1 , the 
terminal answered correctly to the authentication challenge (the second "SIP REGISTER" message). 



Figure 7: Successful PoC registration example 



6.4.4.3 Trigger Points 



Event from 
abstract equation 


Trigger point from 
customer's point of view 


Tecfinical description / protocol part 


*PoCActivated ■ ^ime 
of PoC registration 
attempt 


start: Activation of the PoC 
service on the terminal. 


Start: Protocol: SIP. 

First data packet sent by the terminal containing a "SIP REGISTER" 
message. 


'poCAvailable ■ "'"''^^ 
of successful PoC 
registration attempt 


Stop: PoC available is 
indicated. 


Stop: Protocol: SIP. 

First data packet received containing a "SIP 200 OK" message. 
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6.4.5 PoC Publish Failure Ratio [%] 
6.4.5.1 Abstract Definition 

The PoC publish failure ratio is the probability that the terminal can not successfully publish his PoC service settings to 
the PoC server, after the terminal is registered to the PoC service. 



Remarks: 



To set, update or refresh the PoC service settings, the terminal generates a "SIP PUBLISH" request with XML 
MIME content according to rules and procedures of [17]. 

The terminal shall be registered to the PoC service. 

PoC enabled user equipment may combine the PoC registration and the PoC publish request and may not give 
the user the possibility to do these actions separately. 



6.4.5.2 Abstract Equation 



T^ ^T^ , ,• , 1- •, T^ • r^n unsuccessful PoC publish attempts ,„„^ 

PoC Publish Failure Ratio [%] = ^— xlOO % 

all PoC publish attempts 



6.4.5.3 Trigger Points 



Event from abstract 
equation 


Trigger point from 
customer's point of view 


Teclinical description / protocol part 


PoC publish attempt 


Start: Attempt to publish the 
terminals PoC service 
settings. 


Start: Protocol: SIP. 

First data packet sent by the terminal containing a "SIP 
PUBLISH" message. 


Successful PoC publish 
attempt 


Stop: PoC service settings 
are published. 


Stop: Protocol: SIP. 

First data packet received containing a "SIP 200 OK" 
message. 


Unsuccessful PoC publish 
attempt 


Stop: PoC service settings 
are not published. 


Stop: Protocol: SIP 

Case 1 : Data packet received by the terminal containing a 
message different to "SIP 200 OK". 

Case 2: No message received by the terminal within a 
pre-determined time. 



6.4.6 PoC Publish Time [s] 



6.4.6.1 Abstract Definition 

The PoC publish time is the period of time that it takes to publish the terminal's PoC service settings to the PoC server. 
Remarks: 

• To set, update or refresh the PoC service settings, the terminal generates a "SIP PUBLISH" request with XML 
MIME content according to rules and procedures of [17]. 

• The terminal shall be registered to the PoC service. 

• PoC enabled user equipment may combine the PoC registration and the PoC publish request and may not give 
the user the possibility to do these actions separately. 
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6.4.6.2 Abstract Equation 



PoC Publish Time [s] = (t 



PoCPublishEnd ^PoCPublishStart 



)[S] 



Terminal 



SIP Core 



SIP PUBLISH 



SIP 200 OK 



Figure 8: Example for a successful publish of PoC service settings 



6.4.6.3 Trigger Points 



Event from abstract 
equation 


Trigger point from 

customer's point of 

view 


Technical description / protocol part 


VoCPublishStart ■ '^™^ °^ 
PoC publish attempt 


Start: Attempt to publish 
the terminals PoC 
service settings. 


Start: Protocol: SIP. 

First data packet sent by the terminal containing a "SIP PUBLISH" 
message. 


VoCPublishEnd ■ "'"''^^ °f 

successful PoC publish 
attempt 


Stop: PoC service 
settings are published. 


Stop: Protocol: SIP. 

First data packet received containing a "SIP 200 OK" message. 



6.4.7 PoC Registration Failure Ratio (long) [%] 
6.4.7.1 Abstract Definition 

The PoC registration failure ratio (long) is the probability that the terminal can not successfully be registered to the PoC 
service and publish his PoC service settings. 

Remarks: 

• This QoS parameter is a combination of the PoC registration parameter (see clause 6.4.3) and the PoC pubhsh 
parameter (see clause 6.4.5). It ought to reflect the behaviour of PoC enabled user equipment that may do the 
PoC publish automatically after the PoC register. 

• The terminal shall not be registered to the PoC service. 



6.4.7.2 Abstract Equation 



PoC Registration Failure Ratio (long) [%] = 



R + P 



all PoC registration (long) attempts 



-xlOO% 
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6.4.7.3 Trigger Points 



Event from abstract 
equation 


Trigger point from 
customer's point of view 


Technical description / protocol part 


PoC registration 
attempt 


Start: Activation of the 
PoC service on the 
terminal. 


Start: Protocol: SIP. 

First data packet sent by the terminal containing a "SIP 
REGISTER" message. 


Successful PoC publish 
attempt 


Stop: PoC service settings 
are published. 


Stop: Protocol: SIP. 

First data packet received containing a "SIP 200 OK" message. 


Unsuccessful PoC 
publish attempt 


Stop: PoC service settings 
are not published. 


Stop: Protocol: SIP 

Case 1 : Data packet received by the terminal containing a 
message different to "SIP 200 OK". 

Case 2: No message received by the terminal within a 
pre-determined time. 



6.4.8 PoC Registration Time (long) [s] 

6.4.8.1 Abstract Definition 

The PoC registration time (long) is the combined duration for a SIP registration and a SIP publish. 
Remarks: 

• This QoS parameter is a combination of the PoC registration parameter (see clause 6.4.3) and the PoC publish 
parameter (see clause 6.4.5). It ought to reflect the behaviour of PoC enabled user equipment that may do the 
PoC publish automatically after the PoC register. 

• The terminal shall not be registered to the PoC service. 

6.4.8.2 Abstract Equation 



PoC Registration Time (long) [s] = (t 



PoCPublishEnd ^ PoCActivated 



,)[s] 



Terminal 



SIP Core 



SIP REGISTER 



SIP 401 Unauthorized 



SIP REGISTER 



SIP 200 OK 



SIP PUBLISH 



SIP 200 OK 



Figure 9: Example for a successful PoC Registration (long) 
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6.4.8.3 Trigger Points 



Event from abstract 
equation 


Trigger point from 
customer's point of view 


Technical description / protocol part 


tpoCActivated ■ Time of 
PoC registration 
attempt 


Start: Activation of the 
PoC service on the 
terminal. 


Start: Protocol: SIP. 

First data packet sent by the terminal containing a "SIP 
REGISTER" message 


*PoCPublishEnd ■ ^ilTie Of 

successful PoC publish 
attempt 


Stop: PoC service settings 
are published. 


Stop: Protocol: SIP. 

First data packet received containing a "SIP 200 OK" message. 



6.4.9 PoC Session Initiation Failure Ratio (on-demand) [%] 
6.4.9.1 Abstract Definition 

The PoC session Initiation failure ratio (on-demand) is the probability that a PoC session can not be successfully 
initiated. A PoC session is initiated when the user pushes the PoC button on the terminal (and thereby requests a talk 
burst) and is granted a talk burst (see figure 10). 



Remarks: 



The terminal notifies the user about the granted Talk Burst (e.g. by a "beep"-tone). 

There shall be at least one other participating terminal and the floor shall be idle. In particular, no other 
terminal shall create and send data packets containing speech data (RTP media stream). 

All terminals shall be registered to the PoC service and shall have successfully published their PoC service 
settings. 

There are different signal flows for confirmed and for unconfirmed invitations. In the confirmed case, at least 
one of the invited users has to accept the invitation to the PoC session in order to get the talk burst granted 
(see [16]). If the PoC server supports media buffering, the talk burst confirm is send after the first received 
auto-answer. This automatic answer mode shall be used for the measurements and media buffering shall not be 
supported. In both cases (confirmed and unconfirmed) the trigger points for the measurement are the same. 
Measurement data of confirmed and unconfirmed measurements can not be directly compared. 

This parameter is applicable to different kinds of PoC session initiations, which has an impact on the 
comparability of the measurement data. 

The initial "SIP INVITE" message accepted by the PoC server is an implicit talk burst request. 



6.4.9.2 Abstract Equation 



PoC Session Initiation Failure Ratio (on - demand) [%] 



unsuccessful PoC session initiations 
all PoC session initiations 



xlOO% 



£75/ 



62 



ETSI TS 102 250-2 V1.5.1 (2007-10) 



6.4.9.3 Trigger Points 



Event from abstract 
equation 


Trigger point from 

customer's point of 

view 


Technical description / protocol part 


PoC session initiation 
attempt 


Start: PoC button is 
pushed. 


Start: Protocol: SIP. 

First data packet sent by tfie terminal containing a "SIP 
INVITE" message. 


Successful PoC 
session initiation 
attempt 


Stop: Talk burst granted 
is indicated. 


Stop: Protocol: RTCP:TBCP 

First data packet received by the terminal containing 
"RTCP:TBCP Talk Burst Granted". 


Unsuccessful PoC 
session initiation 
attempt 


Stop: Missing talk burst 
granted indication. 


Stop: Protocol: SIP; RTCP:TBCP. 

Case 1 : First data packet received by the terminal (after 
sending a "SIP INVITE" message) containing an error 
message or redirection message (e.g. a "403 Forbidden" or 
"488 Not Acceptable Here" message). 

Case 2: First data packet received by the terminal (after 
sending a "SIP INVITE" message and receiving a "SIP 200 
OK" message) containing a message different to the 
"RTCP:TBCP Talk Burst Granted" message, e.g. "404 Not 
Found", "SIP 486 Busy Here" or "SIP 403 Forbidden" 
message. 

Case 3: No message received by the terminal within a 
pre-determined time. 



6.4.10 PoC Session Initiation Time (on-demand) [s] 
6.4.10.1 Abstract Definition 

The PoC session initiation time (on-demand) is the time period between pushing the PoC button on the terminal in order 
to initiate a PoC session and being granted the talk burst, e.g. indicated by a "beep"-tone on the terminal. 



Remarks: 



The terminal notifies the user about the granted talk burst (e.g. by a "beep"-tone). 

There shall be at least one other participating terminal and the floor shall be idle. In particular, no other 
terminal shall create and send data packets containing speech data (RTF media stream). 

All terminals shall be registered to the PoC service and shall have successfully published their PoC service 
settings. 

There are different signal flows for confirmed and for unconfirmed invitations. In the confirmed case, at least 
one of the invited users has to accept the invitation to the PoC session in order to get the talk burst granted 
(see [15]). If the PoC server supports media buffering, the talk burst confirm is send after the first received 
auto-answer. This automatic answer mode shall be used for the measurements and media buffering shall not be 
supported. In both cases (confirmed and unconfirmed) the trigger points for the measurement are the same. 
Measurement data of confirmed and unconfirmed measurements can not be directly compared. 

This parameter is applicable to different kinds of PoC session initiations, which has an impact on the 
comparability of the measurement data. 

The initial "SIP INVITE" message accepted by the PoC server is an implicit talk burst request. 
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6.4.10.2 Abstract Equation 



PoC Session Initiation Time (on - demand) [s] = (t 



beep received PoC button pressed 



)[S] 



Terminal 



SIP Core 



SIP INVITE 



SIP 180 Ringing 



SIP 200 OK 



POC Server 



SIP INVITE 



SIP 180 Ringing 



SIP 200 OK 



RTCP:TBCP Talk Burst Granted 



SIP INVITE 

to terminating PoC 

Network 



SIP 180 Ringing 

from terminating PoC 

network 



SIP 200 OK 

from terminating PoC 
network 



Figure 10: Implicit talk burst request procedure at the initiation of the PoC session 



Remark: 



• The dashed arrows in figure 10 only occur in case of a confirmed invitation with manual answer. In this case 
the time that elapses between the "SIP INVITE" message and the reception of the "SIP 200 OK" message 
depends on how fast an invited user on the terminating side accepts the invitation. 



6.4.10.3 Trigger Points 



Event from abstract 
equation 


Trigger point from 
customer's point of view 


Technical description / protocol part 


tpoC button pressed ■ "'"''^^ 
of PoC session initiation 
attempt 


Start: Push PoC button. 


Start: Protocol: SIP. 

First data packet sent by the terminal containing a "SIP 
INVITE" message. 


*beep received ■ Time of 
successful PoC session 
initiation attempt 


Stop: Talk burst granted is 
indicated. 


Stop: Protocol: RTCP:TBCP 

First data packet received by the terminal containing 
"RTCP:TBCP Talk Burst Granted". 
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6.4.1 1 PoC Session Media Parameters Negotiation Failure Ratio 
(pre-establislned) [%] 

6.4.1 1 .1 Abstract Definition 

The PoC session media parameters negotiation failure ratio (pre-established) is the probability that a negotiation 
procedure of media parameters for a posterior pre-established session can not be successfully accomplished. 



Remarks: 



The initial "SIP INVITE" message accepted by the PoC server is not an implicit talk burst request. 

All terminals shall be registered to the PoC service and shall have successfully published their PoC service 
settings. 

"The PoC server performing the controlling PoC function shall determine the codec(s) and media parameters 
that should be used in the PoC session. The preferred media parameters should be determined according to the 
lowest negotiated media parameters (e.g. bandwidth) of the terminals that have joined the PoC session 
(see [14], page 102)". 

"User plane adaptation may be triggered e.g. by roaming or when a new terminal with lower media parameters 
enters the PoC session (see [15], page 103)". 



6.4.1 1 .2 Abstract Equation 



PoC Session Media Parameters Negotiation Failure Ratio (pre - established) [%] = 
unsuccessfLil negotiation attempts 



all negotiation attempts 



-xlOO% 



6.4.11.3 Trigger Points 



Event from abstract 
equation 


Trigger point from 
customer's point of view 


Technical description / protocol part 


PoC session media 
parameters negotiation 
attempt 


Start: PoC terminal 
initiates media parameters 
negotiation. 


Start: Protocol: SIP. 

First data packet sent by the terminal containing a "SIP INVITE" 
message with media parameters. 


Successful PoC session 
media parameters 
negotiation attempt 


Stop: Successful 
parameter negotiation 
indication. 


Stop: Protocol: SIP. 

First "SIP Ack" data packet sent by the terminal after the reception 
of a "SIP OK" message. 


Unsuccessful PoC 
session media 
parameters negotiation 
attempt 


Stop: Media parameter 
negotiation is rejected or 
not indicated. 


Stop: Protocol: SIP. 

Case 1 : First data packet received by the terminal (after sending a 
"SIP INVITE" message and receiving a "SIP 100 TRYING" 
message) containing a message different to "SIP 200 OK"; e.g. a 
""sIP 403 Forbidden" or "SIP 488 Not Acceptable Here" message. 

Case 2: No message received by the terminal within a 
pre-determined time. 
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6.4.12 PoC Session Media Parameters Negotiation Time 
(pre-establislned) [s] 

6.4.12.1 Abstract Definition 

The PoC session media parameters negotiation time (pre-established) describes the time period needed to accomplish a 
successful negotiation of media parameters. 



Remarks: 



The initial "SIP INVITE" message accepted by the PoC server is not an implicit talk burst request. 

All terminals shall be registered to the PoC service and shall have successfully published their PoC service 
settings. 

"The PoC server performing the controlling PoC function shall determine the codec(s) and media parameters 
that should be used in the PoC session. The preferred media parameters should be determined according to the 
lowest negotiated media parameters (e.g. bandwidth) of the terminals that have joined the PoC session 
(see [14], page 102)". 

"User plane adaptation may be triggered e.g. by roaming or when a new terminal with lower media parameters 
enters the PoC session (see [14], page 103)". 



6.4.12.2 Abstract Equation 



PoC Session Media Parameters Negotiation Time (pre - established) [s] = (toi. received " t negotiation initiation 



)[s] 



Terminal 



SIP Core 



SIP INVITE 



SIP 100 Trying 



.STP 900 HK 



SIP ACK 



Figure 1 1 : Media parameters negotiation for pre-established session 



6.4.12.3 Trigger Points 



Event from abstract 
equation 


Trigger point from 
customer's point of view 


Technical description / protocol part 


'negotiation initiation ■ Time of 
PoC pre-established 
session media 
parameters negotiation 
attempt 


Start: PoC terminal initiates 
media parameters negotiation. 


Start: Protocol: SIP. 

First data packet sent by the terminal containing a "SIP 
INVITE" message with Media Parameters. 


tok received ■ Time of 
successful PoC 
pre-established session 
media parameters 
negotiation attempt 


stop: Successful parameter 
negotiation indication. 


Stop: Protocol: SIP. 

First "SIP Ack" data packet sent by the terminal after the 
reception of a "SIP OK" message. 
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6.4.13 PoC Session Initiation Failure Ratio (pre-established) [%] 

6.4.13.1 Abstract Definition 

The PoC session initiation failure ratio (pre-established) is the probability that a pre-established session can not be 
successfully initiated. After the negotiation of media parameters, a pre-established session is initiated when the user 
pushes the PoC button on the terminal (and thereby requests the talk burst) and is granted the talk burst. 

Remarks: 

The terminal notifies the user about the granted talk burst (e.g. by a "beep"-tone). 

The initial "SIP REFER" message accepted by the PoC server is an implicit talk burst request. 

There shall be at least one other participating terminal and the floor shall be idle. In particular, no other 
terminal shall create and send data packets containing speech data (RTP media stream). 

The terminals shall have negotiated the session media parameters with the PoC server. 

All terminals in the PoC session shall be configured to use the auto-answer mode procedure (see [16]). 

There are different signal flows for confirmed and for unconfirmed invitations. In the confirmed case, at least 
one of the invited users has to accept the invitation to the PoC session in order to get the talk burst granted. 
The terminals on the terminating side may be configured to confirm the invitation automatically. This 
auto-answer mode should be used for measurements. In both cases (confirmed and unconfirmed) the trigger 
points for the measurement are the same. Measurement data of confirmed and unconfirmed measurements can 
not be directly compared. 

• This parameter is applicable to different kinds of PoC session initiations, which has an impact on the 
comparability of the measurement data. 

6.4.13.2 Abstract Equation 



PoC Session Initiation Failure Ratio (pre - established) [%] = 

unsuccessful pre - established session initiation attempts 
all pre - established session initiation attempts 



xlOO% 
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6.4.13.3 Trigger Points 



Event from abstract 
equation 


Trigger point from 
customer's point of view 


Technical description / protocol part 


PoC session initiation 
attempt 


Start: PoC button is pushed. 


Start: Protocol: SIP. 

First data packet sent by the terminal containing a "SIP 
REFER" message with the PoC session URL. 


Successful PoC session 
initiation attempt 


Stop: Talk burst granted is 
indicated. 


Stop: Protocol: RTCP:TBCP. 

First data packet received by the terminal containing "Talk 
Burst Granted" message. 


Unsuccessful PoC 
session initiation attempt 


Stop: Missing talk burst 
granted indication. 


Stop: Protocol: SIP; RTCP:TBCP. 

Case 1 : First data packet received by the terminal (after 
sending a "SIP REFER" message) containing a message 
different to the "SIP 202 Accepted" message. 

Case 2: Data packet received by the terminal (after sending a 
"SIP REFER" message and receiving a "SIP 202 Accepted" 
message) containing a message different to "SIP NOTIFY", 
"RTCP:TBCP Connect" or "RTCP:TBCP Talk Burst Granted" 
(e.g. "SIP 404 Not Found", "SIP 486 Busy Here" or "SIP 403 
Forbidden" message). 

Case 3: No message received by the terminal within a 
pre-determined time. 



6.4.14 PoC Session Initiation Time (pre-established) [s] 
6.4.14.1 Abstract Definition 

The PoC session initiation time (pre-established) is the time period between pushing the PoC button on the terminal in 
order to initiate a pre-established session and being granted the talk burst, e.g. indicated by a "beep"-tone on the 
terminal. 

Remarks: 



The terminal notifies the user about the granted talk burst (e.g. by a "beep"-tone). 

The initial "SIP REFER" message accepted by the PoC server is an implicit talk burst request. 

There shall be at least one other participating terminal and the floor shall be idle. In particular, no other 
terminal shall create and send data packets containing speech data (RTP media stream). 

The terminals shall have negotiated the session media parameters with the PoC server. 

All terminals in the PoC session shall be configured to use the auto-answer mode procedure (see [16]). 

There are different signal flows for confirmed and for unconfirmed invitations. In the confirmed case, at least 
one of the invited users has to accept the invitation to the PoC session in order to get the talk burst granted. 
The terminals on the terminating side may be configured to confirm the invitation automatically. This 
auto-answer mode should be used for measurements. In both cases (confirmed and unconfirmed) the trigger 
points for the measurement are the same. Measurement data of confirmed and unconfirmed measurements can 
not be directly compared. 

This parameter is applicable to different kinds of PoC session initiations, which has an impact on the 
comparability of the measurement data. 



6.4.14.2 Abstract Equation 



PoC Session Initiation Time (pre - established) [s] = (t^eep received " tpoc button pressed )[s] 
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Terminal 



SIP Core 



SIP REFER 



SIP 202 Accepted 



SIP NOTIFY 
SIP 200 OK 



POC Server 



SIP RF.FF.R 



SIP 202 Accepted 



SIP NOTIFY 



SIP 200 OK 



RTCP:TBCP Connect 



RTCP:TBCP Acknowledged 



RTCP:TBCP Ta k Burst Granted 



SIP INVITE 

to terminating 
PoC Network 



SIP NOTIFY 
informing invitation 
progress 



NOTE: The dashed arrows in figure 12 only occur in case of a confirmed, manual answer invitation. In this case 
the time period between the "SIP INVITE" message and the reception of the "Talk Burst Granted" 
message depends on how fast an invited user on the terminating side answers to the invitation. 
Furthermore, the "SIP NOTIFY" message is defined as optional (see [15]) and might not be sent by the 
server at all. For this reason the automatic answer mode shall be used during measurements. 

Figure 12: Talk burst request procedure of a pre-established PoC session 

6.4.14.3 Trigger Points 



Event from abstract 
equation 


Trigger point from 
customer's point of view 


Technical description / protocol part 


*PoC button pressed ■ ^ime of 
PoC session initiation 
attempt 


Start: Push PoC button. 


Start: Protocol: SIP. 

First data packet sent by the terminal containing a "SIP 
REFER" message with the PoC session description. 


Wp received ■ Time of 
successful PoC session 
initiation attempt 


Stop: Talk burst granted is 
indicated. 


Stop: Protocol: RTCP:TBCP. 

First data packet received by the terminal containing "Talk 
Burst Granted" message. 



6.4.15 PoC Session Setup Failure Ratio (on-(deman(d) [%] 
6.4.15.1 Abstract Definition 

The PoC session setup failure ratio (on-demand) is the probability that a terminal can not successfully register to the 
PoC service and initialize an on-demand session. 
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Remarks: 

• This QoS parameter is a combination of the PoC registration parameter and the PoC session initiation 
parameter. It is ought to reflect the behaviour of PoC enabled user equipment. 

• Data between confirmed and unconfirmed measurements cannot be compared directly. 

6.4.15.2 Abstract Equation 

Let R be the number of unsuccessful registration attempts and let S be the number of unsuccessful session initiations 
following a successful registration. 

Then: 



PoC Session Setup Failure Ratio (on - demand) [%] : 



R + S 



all PoC session setup attempts 



-xlOO% 



6.4.15.3 Trigger Points 



Event from abstract 
equation 


Trigger point from 
customer's point of view 


Technical description / protocol part 


PoC registration attempt 


Start: Activation of the PoC 
service on the terminal. 


Start: Protocol: SIP. 

First data packet sent by the terminal containing a "SIP 
REGISTER" message. 


Successful PoC session 
initiation attempt 


Stop: PoC available is 
indicated. 


Stop: Protocol: RTCP:TBCP 

First data packet received by the terminal containing 
"RTCP;TBCP Talk Burst Granted". 


Unsuccessful PoC 
session Initiation attempt 


Stop: Missing Talk Burst 
Granted indication. 


Stop: Protocol: SIP; RTCP:TBCP. 

Case 1 : First data packet received by the terminal (after 
sending a "SIP INVITE" message) containing an error 
message or redirection message (e.g. a "403 Forbidden" or 
"488 Not Acceptable Here" message). 

Case 2: First data packet received by the terminal (after 
sending a "SIP INVITE" message and receiving a "SIP 200 
OK" message) containing a message different to the 
"RTCP:TBCP Talk Burst Granted" message, e.g. "404 Not 
Found", "SIP 486 Busy Here" or "SIP 403 Forbidden" 
message. 

Case 3: No message received by the terminal within a 
pre-determined time. 



6.4.16 PoC Session Setup Failure Ratio (pre-established) [%] 
6.4.16.1 Abstract Definition 

The PoC session setup failure ratio (pre-established) is the probability that a terminal can not successful register to the 
PoC service and initialize a pre-established session. 



Remarks: 



This QoS parameter is a combination of the PoC registration parameter and the PoC session initiation 
parameter. It is ought to reflect the behaviour of PoC enabled user equipment. 

Data between confirmed and unconfirmed measurements cannot be compared directly. 
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6.4.16.2 Abstract Equation 

Let R be the number of unsuccessful registration attempts and let S be the number of unsuccessful pre-established 
session media parameters negotiations following a successful registration. Let Tbe the number of unsuccessful session 
initiation attempts, which followed after a successful registration and after a successful pre-established session media 
parameters negotiation. 

Then: 



PoC Session Setup Failure Ratio (pre - established) [%] = 



R-hS-hT 



all PoC session setup attempts 



-xlOO% 



6.4.16.3 Trigger Points 



Event from abstract 
equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


PoC registration 
attempt 


Start: Activation of the PoC 
service on the terminal. 


Start: Protocol: SIP. 

First data packet sent by the terminal containing a "SIP 
REGISTER" message. 


Successful PoC session 
initiation attempt 


Stop: PoC available is indicated. 


Stop: Protocol: RTCP:TBCP 

First data packet received by the terminal containing 
"RTCP;TBCP Talk Burst Granted". 


Unsuccessful PoC 
session initiation 
attempt 


Stop: Missing talk burst granted 
indication. 


Stop: Protocol: SIP; RTCP:TBCP. 

Case 1 : First data packet received by the terminal (after 
sending a "SIP REFER" message) containing a message 
different to the "SIP 202 Accepted" message. 

Case 2: Data packet received by the terminal (after sending 
a "SIP REFER" message and receiving a "SIP 202 
Accepted" message) containing a message different to "SIP 
NOTIFY", "RTCP:TBCP Connect" or "RTCP:TBCP Talk 
Burst Granted" (e.g. "SIP 404 Not Found", "SIP 486 Busy 
Here" or "SIP 403 Forbidden" message). 

Case 3: No message received by the terminal within a 
pre-determined time. 



6.4.17 PoC Session Setup Time [s] 
6.4.17.1 Abstract Definition: 

The PoC session setup time is the time period for the registration to the PoC service plus the time period for the 
initiation of a PoC session. 



Remarks: 



This QoS parameter is a combination of the PoC registration parameter and the PoC session initiation 
parameter. It is ought to reflect the behaviour of PoC enabled user equipment. 

Data between confirmed and unconfirmed measurements cannot be compared directly. 

Data between on-demand sessions and pre-established sessions cannot be compared directly. 



6.4.17.2 Abstract Equation 



PoC Session Setup Time [s] = (t 



beep received PoC Activated 



i)[s] 
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Figure 13: PoC session setup time and PoC push to speaic time 



6.4.17.3 Trigger Points 



Event from abstract 
equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


*PoCActivated ■ Time of 
PoC registration 
attempt 


Start: Activation of the PoC 
service on tlie terminal. 


Start: Protocol: SIP. 

First data packet sent by the terminal containing a "SIP 
REGISTER" message 


*beep received ■ Time of 
successful PoC 
registration attempt 


Stop: PoC available Is indicated. 


Stop: Protocol: RTCP:TBCP 

First data packet received by the terminal containing 
"RTCP;TBCP Talk Burst Granted". 



6.4.18 PoC Push to Speak Failure Ratio [%] 
6.4.18.1 Abstract Definition 

The PoC Push to speak failure ratio is the probability that terminal A can not successfully set up a PoC session and start 
with speech leading to no other terminal receiving speech. 



Remarks: 



This QoS parameter is a combination of the PoC session setup parameter and the PoC talk burst cut-off 
parameter (see clause 6.4.30). It is ought to reflect the behaviour of PoC enabled user equipment. 

All terminals shall be registered to the PoC service and shall have successfully published their PoC service 
settings. 

Data between confirmed and unconfirmed measurements cannot be compared directly. 



6.4.18.2 Abstract Equation 

Let S be the number of unsuccessful PoC session setup attempts and let T be the number of talk burst cut-offs following 
a successful PoC session setup. 

Then: 



PoC Push to Speak Failure Ratio [%] : 



S + T 



all PoC push to speak attempts 



-xlOO% 
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6.4.18.3 Trigger Points 



Event from abstract 
equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


PoC registration 
attempt 


Start: Activation of the PoC 
service on the terminal. 


Start: Protocol: SIP. 

First data packet sent by the terminal containing a "SIP 
REGISTER" message. 


No unintended speech 
cut-off on terminal B 


Stop: Sound received by 
terminal B. 


Stop: Protocol: RTP. 

First data packet received by terminal B containing speech 
data. 


Unintended speech 
cut-off on terminal B 


Stop: Terminal B does not 
receive speech or does not 
receive the whole speech. 


Stop: Protocol: RTP. 

Case 1 : No packet containing speech data (RTP media 
stream) received by terminal B within a pre-determined time. 
The timeout should be chosen greater than the average 
voice delay (see clause 6.6.32). 

Case 2: The media stream is only partially received by 
terminal B. Some of the data packets containing speech data 
(RTP media stream) have not been received by terminal B. 



6.4.1 9 PoC Push to Speak Time [s] 
6.4.19.1 Abstract Definition 

The PoC push to speak time is the period of time that it takes to setup a PoC session and start with speech in addition to 
the delay until terminal B receives the speech (as defined in clause 6.4.32). 



Remarks: 



This QoS parameter is a combination of the PoC session setup time parameter and the PoC voice transmission 
delay parameter (see clause 6.4.32). It ought to reflect the behaviour of PoC enabled user equipment. 

All terminals shall be registered to the PoC service and shall have successfully published their PoC service 
settings. 

Data between confirmed and unconfirmed measurements cannot be compared directly. 



6.4.19.2 Abstract Equation 



PoC Push to Speak Time [s] = (t^_i,,^,, - tpoCAcdvated )[s] 



6.4.19.3 Trigger Points 



Event from abstract 
equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


tpoCActivated ■ Time of 
PoC registration 
attempt 


Start: Activation of the PoC 
service on the terminal. 


Start: Protocol: SIP. 

First data packet sent by the terminal containing a "SIP 
REGISTER" message. 


tejears ■ Time of output 
at terminal B 


Stop: Sound received by 
terminal B. 


Stop: Protocol: RTP. 

First data packet received by terminal B containing speech 

data. 
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6.4.20 PoC Session Leaving Failure Ratio (on-demand) [%] 

6.4.20.1 Abstract Definition 

The PoC session leaving failure ratio (on-demand) is the probability that the user can not leave the PoC session he is 
participating. 

Remarks: 

• When a PoC session is left, the terminal is still registered to the PoC service. 

• PoC enabled user equipment may not give the user the possibility to leave a PoC session explicitly. The PoC 
session leave request may only be sent when the terminal deregisters from the PoC service. 

• The terminal shall be registered to the PoC service participating in a PoC session. 

6.4.20.2 Abstract Equation 



PoC Session Leaving Failure Ratio (on - demand) [%] = 
unsuccessfiil PoC session leaving attempts 



all PoC session leaving attempts 



xlOO% 



6.4.20.3 Trigger Points 



Event from abstract 
equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


PoC session leaving 
attempt 


Start: Leaving the participating 
PoC session. 


Start: Protocol: SIP. 

First data packet sent by the terminal containing a 
"SIP BYE" message. 


Successful PoC session 
leaving attempt 


Stop: PoC session left is 
indicated. 


Stop: Protocol: SIP. 

First data packet received by the terminal containing 
a "SIP 200 OK" message. 


Unsuccessful PoC 
session leaving attempt 


Stop: Terminal is still connected 
to the PoC session. 


Stop: Protocol: SIP. 

Case 1 : First data packet received by the terminal 
(after sending the "SIP BYE" message) containing a 
message different to "SIP 200 OK". 

Case 2: No message received by the terminal within 
a pre-determined time. 



6.4.21 PoC Session Leaving Time (on-demand) [s] 
6.4.21.1 Abstract Definition 

The PoC session leaving time (on-demand) is the time period between sending the on-demand session leaving request 
and being disconnected from the on-demand session. 

Remarks: 

• When a PoC session is left, the terminal is still registered to the PoC service. 

• PoC enabled user equipment may not give the user the possibility to leave a PoC session explicitly. The PoC 
session leave request may only be sent when the terminal de-registers from the PoC service. 

• The terminal shall be registered to the PoC service participating in a PoC session. 
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6.4.21 .2 Abstract Equation 



PoC Session Leaving Time (on - demand)[s] = (t,,,,i„„i,ft - t.^ssion leave request )[s] 



Terminal 



SIP BYE 



SIP 200 OK 



SIP Core 



Figure 14: Successful PoC session leaving 



6.4.21 .3 Trigger Points 



Event from 
abstract equation 


Trigger point from 
customer's point of view 


Technical description / protocol part 


session leave request ■ 
Time of PoC 
session leaving 
attempt 


Start: Leaving the 
participating PoC session. 


Start: Protocol: SIP. 

First data packet sent by the terminal containing a "SIP BYE" 
message. 


tsesslon left ■ Time of 
successful PoC 
session leaving 
attempt 


Stop: PoC session left is 
indicated. 


Stop: Protocol: SIP. 

First data packet received by the terminal containing a "SIP 
200 OK" message. 



6.4.22 PoC Session Leaving Failure Ratio (pre-established) [%] 
6.4.22.1 Abstract Definition 

The PoC session leaving failure ratio (pre-established) is the probability that the user can not leave the PoC 
pre-established session he is participating. 



Remark: 



The PoC session was established using pre-established signalling. 

The terminal may not give the user the possibility to leave a PoC session explicitly. The PoC session leave 
request may only be sent when the terminal deregisters from the PoC service. 



6.4.22.2 Abstract Equation 



PoC Session Leaving Failure Ratio (pre - established) [%] 
unsuccessfLil PoC session leaving attempts 



all PoC session leaving attempts 



-xlOO% 
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6.4.22.3 Trigger Points 



Event from abstract 
equation 


Trigger point from 
customer's point of view 


Technical description / protocol part 


PoC session leaving 
attempt 


Start: Leaving the 
participating PoC session. 


Start: Protocol: SIP. 

First data packet sent by the terminal containing a "SIP 
REFER BYE" message. 


Successful PoC session 
leaving attempt 


Stop: Terminal has 
successfully left the PoC 
session. 


Stop: Protocol: SIP. 

First data packet received by the terminal containing a "SIP 
202 ACCEPTED" message. 


Unsuccessful PoC session 
leaving attempt 


Stop: Terminal is still 
connected to the PoC 
session. 


Stop: Protocol: SIP 

Case 1 : First data packet received by the terminal (after 
sending the "SIP REFER BYE" message) containing a 
message different to "SIP 202 Accepted". 

Case 3: No message received by the terminal within a 
pre-determined time. 



6.4.23 PoC Session Leaving Time (pre-established) [s] 
6.4.23.1 Abstract Definition 

The PoC session leaving time (pre-established) is the time period between sending the PoC session leaving request and 
being disconnected from the Pre-established session. 

Remark: 

• The PoC session was established using Pre-established signalling. 

• The terminal may not give the user the possibility to leave a PoC session explicitly. The PoC session leave 
request may only be sent when the terminal deregisters from the PoC service. 



6.4.23.2 Abstract Equation 



PoC Session Leaving Time (pre - established) [s] = (t ,,,,;„„ 1,^ - t,essionieaverequest)[s] 



Terminal 



SIP Core 



SIP REFER BYE 



SIP 202 ACCEPTED 



Figure 15: Successful PoC session leaving (Pre-established session) 
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6.4.23.3 Trigger Points 



Event from abstract 
equation 


Trigger point from 
customer's point of view 


Technical description / protocol part 


'session leave request ■ Time of 
PoC session leaving 
attempt 


Start: Leaving the 
participating PoC session. 


Start: Protocol: SIP. 

First data packet sent by the terminal containing a "SIP 
REFER BYE" message. 


tsession left ■ Time of 
successful PoC session 
leaving attempt 


Stop: Terminal has 
successfully left the PoC 
session. 


Stop: Protocol: SIP. 

First data packet received by the terminal containing a "SIP 
202 ACCEPTED" message. 



6.4.24 PoC Deregistration Failure Ratio [%] 
6.4.24.1 Abstract Definition 

The PoC deregistration failure ratio is the probability that the user can not be deregistered from the Push to Talk over 
Cellular service when requested. 



Remark: 



The terminal shall be registered to the PoC service. 



6.4.24.2 Abstract Equation 



PoC Deregistration Failure Ratio [%] = 



unsuccessfial PoC deregistration attempts 
all PoC deregistration attempts 



xlOO% 



6.4.24.3 Trigger Points 



Event from abstract 
equation 


Trigger point from 
customer's point of view 


Technical description / protocol part 


PoC deregistration attempt 


Start: Deactivation of the 
PoC service on the terminal. 


Start: Protocol: SIP. 

First data packet sent by the terminal containing a "SIP 
Register" message, where the "Expires" header is set to 0. 


Successful PoC 
deregistration attempt 


Stop: PoC unavailable is 
indicated. 


Stop: Protocol: SIP. 

First data packet received by the terminal containing a "SIP 
200 OK" message. 


Unsuccessful PoC 
deregistration attempt 


Stop: PoC unavailable 
indication is not given within 
a predetermined time. 


Stop: Protocol: SIP. 

Case 1 : First data packet received by the terminal (after 
sending the second "SIP REGISTER" message) containing a 
message different to "SIP 200 OK". 

Case 2: No message received by the terminal within a 
pre-determined time. 
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6.4.25 PoC Deregistration Time [s] 



6.4.25.1 Abstract Definition 

The PoC deregistration time is the time period between the deregistration request and the successful deregistration from 
the PoC service. 

Remark: 



• The terminal shall be registered to the PoC service. 

6.4.25.2 Abstract Equation 



PoC Deregistration Time [S] = (tpocderegistered "tderegistration request )[S] 



Terminal 



SIP Core 



SIP REGISTER 



SIP 401 UNAUTHORIZED 



SIP REGISTER 



SIP 200 OK 



Figure 16: Successful PoC deregistration example 



6.4.25.3 Trigger Points 



Event from 
abstract equation 


Trigger point from 
customer's point of view 


Technical description / protocol part 


'deregistration request ■ 
Time of PoC 
deregistration 
attempt 


Start: Deactivation of the PoC 
service on the terminal. 


start: Protocol: SIP. 

First data packet sent by the terminal containing a "SIP Register" 
message, where the "Expires" header is set to 0. 


'poC deregistered ■ 
Time of successful 
PoC deregistration 
attempt 


Stop: PoC unavailable is 
indicated. 


Stop: Protocol: SIP. 

First data packet received by the terminal containing a "SIP 200 
OK" message. 



6.4.26 PoC Busy Floor Response Failure Ratio [%] 
6.4.26.1 Abstract Definition 

The PoC busy floor response failure ratio is the probability that, once in a PoC session, the talk burst request from the 
terminal fails. 



Remark: 



The terminal shall be within an active PoC talk session. Thus, there shall be at least one other participating 
terminal. 
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For the special case of requesting the idle floor, there are defined further QoS parameters (see clauses 6.4.28 
and 6.4.29). 



6.4.26.2 Abstract Equation 



PoC Busy Floor Response Failure Ratio [%] = 



unsuccessfiil talk burst requests 
all talk burst requests 



xlOO% 



6.4.26.3 Trigger Points 



Event from abstract 
equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


PoC talk burst request 


Start: Push PoC button. 


Start: Protocol: RTCP:TBCP. 

First data packet sent by the terminal containing a 
"RTCP:TBCP Talk Burst Request" message. 


Successful PoC talk 
burst request 


Stop: Current floor state is 
indicated. 


Stop: Protocol: RTCP:TBCP. 

First data packet received by the terminal containing 
information about the floor state. 


Unsuccessful PoC talk 
burst request 


Stop: No talk burst response is 
indicated (e.g. grant, queued). 


Stop: Protocol: RTCP:TBCP. 

No message received by the terminal within a 
pre-determined time. 



6.4.27 PoC Busy Floor Response Time [s] 
6.4.27.1 Abstract Definition 

The PoC busy floor response time is the is the time period between requesting the talk burst and receiving the indication 
the floor is busy within an already established PoC session. 

Remarks: 

• The terminal shall be within an active PoC talk session. Thus, there shall be at least one other participating 
terminal. 

• For the special case of requesting the idle floor, there are defined further QoS parameters (see clauses 6.4.28 
and 6.4.29). 



6.4.27.2 Abstract Equation 



PoC Busy Floor Response Time [s] = (tfl„„„esponse " tfioor request )[s] 
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Terminal 



Floor Response 
Time "^ 



PoC Server 



RTCP:TBCP Floor 
Request 



RTF Queued 



Figure 17: Example for a busy floor response 



6.4.27.3 Trigger Points 



Event from abstract 
equation 


Trigger point from 
customer's point of view 


Technical description / protocol part 


tfloor request: Time of PoC 

talk burst request 


Start: Push PoC button. 


Start: Protocol: RTCP:TBCP. 

First data packet sent by the terminal containing a 
"RTCP:TBCP Talk Burst Request" message. 


*floor response : Time of 
successful PoC talk burst 
request 


Stop: Current floor state Is 
indicated. 


Stop: Protocol: RTCP:TBCP. 

First data packet received by the terminal containing 
information about the floor state. 



6.4.28 PoC Talk Burst Request Failure Ratio [%] 
6.4.28.1 Abstract Definition 

The PoC talk burst request failure ratio is the probability that, once in a PoC session, the terminal's request of the idle 
floor fails. 



Remarks: 



The terminal shall be within an active PoC session. 

There shall be at least one other participating terminal and the floor shall be idle. In particular, no other 
terminal shall create and send data packets containing speech data (RTP media stream). 

This parameter is defined explicitly because the server's response time and failure ratio to a request of the idle 
floor may be different to the response time and response failure ratio of a busy floor. 



6.4.28.2 Abstract Equation 



PoC Talk Burst Request Failure Ratio [%] ■ 



unsuccessfiil talk burst requests 
all talk burst requests 



xlOO% 
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6.4.28.3 Trigger Points 



Event from abstract 
equation 


Trigger point from 
customer's point of view 


Technical description / protocol part 


PoC talk burst request 


Start: Push PoC button. 


Start: Protocol: RTCP:TBCP. 

First data packet sent by the terminal containing a 
"RTCP:TBCP Talk Burst Request" message. 


Successful PoC talk 
burst request 


Stop: Talk burst granted is 
indicated. 


Stop: Protocol: RTCP:TBCP. 

First data packet received by the terminal containing a 
"RTCP:TBCP Talk Burst Granted" message. 


Unsuccessful PoC talk 
burst request 


Stop: Talk burst granted is not 
indicated. 


Stop: Protocol: RTCP:TBCP. 

Case 1 : First data packet received by the terminal 
containing a floor state different to "RTCP:TBCP Talk 
Burst Granted". Possible floor states are listed in [14]. 

Case 2: No message received by the terminal within a 
predetermined time. 



6.4.29 PoC Talk Burst Request Time [s] 
6.4.29.1 Abstract Definition 

The PoC talk burst request time is the time period between requesting the talk burst and being granted the previously 
idle floor within an already established PoC session. 



Remarks: 



The terminal shall be within an active PoC session. 

There shall be at least one other participating terminal and the floor shall be idle. In particular, no other 
terminal shall create and send data packets containing speech data (RTP media stream). 

This parameter is defined explicitly because the server's response time and failure ratio to a request of the idle 
floor may be different to the response time and response failure ratio of a busy floor. 



6.4.29.2 Abstract Equation 



PoC Talk Burst Request Time [s] = (t 



tloor granted floor request 



t)[s] 




Talk Burst Request 
Time 



Figure 18: Example for a successful talk burst request 
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6.4.29.3 Trigger Points 



Event from abstract 
equation 


Trigger point from 
customer's point of view 


Technical description / protocol part 


tfloor request: Time of PoC 

talk burst request 


Start: Push PoC button. 


Start: Protocol: RTCP:TBCP. 

First data packet sent by the terminal containing a 
"RTCP:TBCP Talk Burst Request" message. 


tfloorgranted^Timeof 

successful PoC talk burst 
request 


Stop: Talk burst granted is 
indicated. 


Stop: Protocol: RTCP:TBCP. 

First data packet received by the terminal containing a 
"RTCP:TBCP Talk Burst Granted" message. 



6.4.30 PoC Talk Burst Cut-off Ratio [%] 
6.4.30.1 Abstract Definition 

The PoC talk burst cut-off ratio is the probabihty that the terminal on the originating side (terminal A) has the floor and 
creates and sends data packets containing speech data (RTP media stream), but the stream does not arrive (or arrives 
only partly) at the terminating side (terminal B). 



Remarks: 



There shall be at least one other active participating terminal and the floor shall be granted to terminal A. In 
particular, no other terminal shall create and send data packets containing speech data (RTP media stream). 

The implementation of a stop-talking timer is mandatory on the server side. When a user is granted a talk 
burst, the PoC server resets this stop-talking timer. When the timer expires, the PoC server revokes the talk 
burst from the user (see [14]). Hence this situation (talk burst revoked because of a timeout) shall not be 
considered for measurements. 

The time of a talk burst shall be shorter than the network-defined stop-talking timeout. 



6.4.30.2 Abstract Equation 



_, ^ ^ „ „ ^ jTJT T^ • r^ n dropped talk bursts , . . ^ 

PoC Talk Burst Cut - off Ratio [%] = — ^^ x 100 % 

all talk bursts 



Terminal A 



PoC Server 



Terminal B 



Terminal A creates 
speech 



Floor idle 



RTCP:TBCP: Talk Burst 
Request 



RTCP:TBCP: Talk Burst 
Granted 



RTP: Media Stream 



RTCP:TBCP: Talk Burst Taken 



RTP: Media Stream 



Terminal B does not receive 
the complete speech 



Figure 19: PoC talk burst cut-off 
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6.4.30.3 Trigger Points 



Event from abstract 
equation 


Trigger point from 
customer's point of view 


Technical description / protocol part 


PoC talk burst granted 
and start of speech on 
terminal A 


Start: Talk burst granted is 
indicated. Speech starts. 


Start: Protocol: RTP. 

First data packet sent by terminal A containing speech 

data. 


No unintended speech 
cut-off on terminal B 


Stop: Sound received by 
terminal B. 


Stop: Protocol: RTP. 

First data packet received by terminal B containing 
speech data. 


Unintended speech 
cut-off on terminal B 


Stop: Terminal B does not 
receive speech or does not 
receive the whole speech. 


Stop: Protocol: RTP. 

Case 1 : No packet containing speech data (RTP media 
stream) received by terminal B within a pre-determined 
time. The timeout should be chosen greater than the 
average voice delay (see clause 6.6.32). 

Case 2: The media stream is only partially received by 
terminal B. Some of the data packets containing speech 
data (RTP media stream) have not been received by 
terminal B. 



6.4.31 PoC Talk Burst Packet Drop Ratio [%] 

6.4.31.1 Abstract Definition 

The PoC talk burst packet drop ratio is the ratio between the number of data packets containing speech data sent by the 
terminal on the originating side (terminal A) and the number of data packets containing speech data received on the 
terminating side (terminal B). 

Remarks: 

• There shall be at least one other active participating terminal and the floor shall be granted to terminal A. In 
particular, no other terminal shall create and send data packets containing speech data (RTP media stream). 

• The implementation of a stop-talking timer is mandatory on the server side. When a user is granted a Talk 
Burst, the PoC server resets this stop-talking timer. When the timer expires, the PoC server revokes the talk 
burst from the user (see [14]). Hence this situation (talk burst revoked because of a timeout) shall not be 
considered for measurements. 

• The time of a talk burst shall be shorter than the network-defined stop-talking timeout. 
This ratio shall get calculated on a per-burst basis. 

6.4.31.2 Abstract Equation 



PoC Talk Burst Packet Drop Ratio [%] ■■ 



dropped RTP speech packets 
all sent RTP speech packets 



xlOO% 
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6.4.31.3 Trigger Points 



Event from abstract 
equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


PoC talk burst granted 
and start of speech on 
terminal A 


Start: Talk burst granted is 
indicated. Speech starts. 


Stop: Protocol: RTP. 

First data packet sent by terminal A containing speech data. 


End of speech on 
terminal B 


Stop: End of speech is indicated 
or timeout occurred after 
terminal B has received speech. 


Stop: Protocol: RTP. 

Case 1 : First packet received by the terminal containing a 
"RTP: Last Packet" message after a data packet containing 
speech data has been received by terminal B. 

Case 2: No packet containing a "RTP: Last Packet" message 
received by terminal B within a pre-determined time after a 
data packet containing speech data has been received by 
terminal B. 



6.4.32 PoC Voice Transmission Delay (first) [s] 
6.4.32.1 Abstract Definition 

The parameter PoC voice transmission delay (first) describes the period of time between a terminal sending speech data 
(RTP media stream) and the first terminal receiving the speech data for the first talk burst after a PoC session has been 
established successfully. 



Remarks: 



Without loss of generality, the PoC session consists only of two active terminals (A and B) and terminal A is 
trying to create and send data packets containing speech data (RTP media stream). Thus, terminal B is the one 
who should receive the corresponding RTP media stream. 

Server side buffering has a high impact on measurement results. Depending on the configuration of the server, 
the PoC voice transmission delay (first) might in fact just describe the transmission delay between the server 
and terminal B. To avoid buffering at server side, confirmed indication shall be used. 

Terminal A shall create an RTP media stream immediately after being granted the talk burst. 

This parameter is measured on the transport layer. Thus the measured value may be smaller than the real user 
perceived voice delay. The perceived delay also depends on the encoding/decoding speed of the terminals. 



6.4.32.2 Abstract Equation 



PoC Voice Transmission Delay (first) [s] = [t^j,^^,, - tA_.speaks)[s] 
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Terminal A 



PoC Server 



Terminal B 



SIP session establishment 
with terminal #1 



RTCP:TBCP Floor 
Granted 



SIP session establishment 
with terminal #2 



RTCP:TBCP Floor Taken 




] PoC Voice 
delay (first) 



RTP Media Stream 



Figure 20: PoC voice transmission delay (first) and PoC voice transmission delay (others) 

6.4.32.3 Trigger Points 



Event from abstract 
equation 


Trigger point from 
customer's point of view 


Technical description / protocol part 


Vspeaks : Time of input at 
terminal A 


Start: Terminal A got the 
talk burst granted and 
creates an RTP media 
stream (starts talking). 


Start: Protocol: RTP. 

First data packet sent by terminal A containing speech data. 


*B_hears ■ Time of output at 
terminal B 


Stop: Sound received by 
terminal B. 


Stop: Protocol: RTP. 

First data packet received by terminal B containing speech 
data. 



6.4.33 PoC Voice Transmission Delay (otiners) [s] 
6.4.33.1 Abstract Definition 

The parameter PoC voice transmission delay (others) describes the period of time between a terminal sending speech 
data (RTP media stream) and the first terminal receiving the speech data (within an already established PoC session). 



Remarks: 



Without loss of generality, the PoC session consists only of two active terminals (A and B) and terminal A is 
trying to create and send data packets containing speech data (RTP media stream). Thus, terminal B is the one 
who should receive the corresponding RTP media stream. 

Server side buffering has a high impact on measurement results. Depending on the configuration of the server, 
the PoC voice transmission delay (first) might in fact just describe the transmission delay between the server 
and terminal B. To avoid buffering at server side, confirmed indication shall be used. 

Terminal A shall create an RTP media stream immediately after being granted the talk burst. 

This parameter is measured on the transport layer. Thus the measured value may be smaller than the real user 
perceived voice delay. The perceived delay also depends on the encoding/decoding speed of the terminals. 

The voice delays on the terminating site depend on where the terminals are located (e.g. in another cell or 
another network). 
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6.4.33.2 Abstract Equation 



PoC Voice Transmission Delay (others) [s] = (tghears " tA_speaks)[s] 



6.4.33.3 Trigger Points 



Event from abstract 
equation 


Trigger point from 
customer's point of view 


Technical description / protocol part 


Vspeaks : Time of input at 
terminal A 


Start: Terminal A got the talk 
burst granted and creates an 
RTP media stream (starts 
talking). 


Start: Protocol: RTP. 

First data packet sent by terminal A containing 
speech data. 


tB.hears ■ Time of output at 
terminal B 


Stop: Sound received at 
terminal B. 


Stop: Protocol: RTP. 

First data packet received by terminal B containing 
speech data. 



6.4.34 PoC Speech Quality 

To be defined. 

6.4.35 Group Management QoS Parameter 

To be defined. 

6.4.36 Group Document relatecd QoS Parameter 

To be defined. 

6.4.37 Instant Message QoS Parameter 

To be defined. 

6.5 Streaming Video 

6.5.1 Definitions 

6.5.1 .1 Streaming Session or Session 

RFC 2326 [8] defines a session as "a complete RTSP "transaction", e.g. the viewing of a movie. A session typically 
consists of a client setting up a transport mechanism for the continuous media stream (SETUP), starting the stream with 
PLAY or RECORD, and closing the stream with TEARDOWN". 

Referring to figure 21 this means that the session starts at (B) and stops at (G). 

6.5.2 Prerequisites 



Precondition 


Covered by 


Reference document 


Comment 


Network Accessibility 
given 


Network Accessibility Indicator 






PDP context activated 
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6.5.3 Streaming Scenarios 

The following two clauses describe different streaming scenarios. The first one is a generic approach in order to 
understand the main principles and identify the relevant protocols and communication procedures. 

6.5.3.1 Generic Streaming Signalling Flow 

A generic signal flow description for streaming is shown in figure 21. The client communicates with the web server and 
media server entities and uses different protocols during the complete procedure, e.g. RTP, RTSP, RTCP, HTTP. 

The next table gives a basic description of the protocols and their usage. 



Protocol 


Reference in 
figure 21 


Description 


HTTP 


A 


Used for the retrieval of the streaming file description data. 


RTSP 


B,C,F,G 


RTSP is an application-level protocol. It provides different methods for the control of 
real-time data, e.g. audio/video (see note 1). 


RTP 


D 


RTP is used for the transmission of real-time data, e.g. audio/video (see note 2). 


RTCP 


E 


RTCP is the control protocol for RTP. 1st main function is the provision of a quality 
feedback. 


NOTE 1 : RTSP is not responsible for the delivery of the data, this is done by RTP. 

NOTE 2: RTP is only used for the delivery of the data. No control and/or QoS are included. 



o 

o 

o 

Client 

o 

o 
o 
o 




HTTP GET 




Web 
Server 


^ 


Session Description 




^H 


RTSP: SETUP 






Media 
Server 


-^ 




RTSP: PLAY 




w 


^ 
-^ 


RTP Audio 




-- 


RTP Video 






RTCP 






^ 


Example: RTSP: PAUSE 






^ 


CLOSE 













Figure 21 : Generic session signalling flow, based on Schulzrinne 

Referring to figure 21 and the definition of a session in clause 4.8.1.1 it is possible to divide the communication of the 
client with the server side in two phases: 

• In the first phase the client communicates with the web server in order to get a description of the file to be 
streamed. The used protocol is HTTP. Starting point is (A) and ending point is (B). 

• In the second phase starts the communication with the media server which is finally delivering the stream. This 
means that the session starts at (B) and stops at (G). Different protocols are used in this phase (RTSP, RTP, 
RTCP). 
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6.5.3.2 Parameter Overview Chart 

Figure 22 gives an overview of the defined QoS parameters with their trigger points fi^om customer's point of view. 



Parameters 



Trigger Points 

from 

Customer's 

point of View 



Streaming 

Service Non- 

Accessability [%] 



r 



streaming 

Service Access Time 

[s], (Precond. Servic ; 

Access^ 



Streaming Reproduction 

Start Failure Ratio [%], 

(Precond. Service Access) 



Streaming Reproduction 
Start Deiay [s], 
(Precond. Service Access) 



Stream Request 



to 



Buffering Message 
appears on Player 



t1 



Streaming Reproduction 
Cut-Off Ratio [%], 
(Precond.: Service Access^ 



Streaming Video Quality [] 



Streaming Audio Quality [] 
[M0S-BS1 387-1] 



Streaming Audio / Video 
De-Synchronisation [%] 



Stream Reproduction 



intentional 

Termination of 

Session 



Figure 22: Parameter overview with trigger points 



6.5.4 Streaming Service Non-Accessibility [%] 



6.5.4.1 Abstract Definition 

The parameter Streaming Service Non- Accessibility describes the probability that the first data packet of the stream 
cannot be received by the UE when requested by the user. The "packet reception" is completed by appearance of the 
"buffering" message on the player at user side. 

The first data packet refers to RTP protocol. 

6.5.4.2 Abstract Equation 



Streaming Service Non - Accessibility [%] 



unsuccessful stream request attempts 
all stream request attempts 



xlOO% 



6.5.4.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


Service access attempt 


start: Stream request. 


Start: 

■ WAP 1.x, WAP 2.x: 
WSP Disconnect; 

WAP 2.x: TCP SYN towards streaming 
platform. 


Successful attempt 


Stop: "Buffering" message. 


Stop: Reception of first data packet. 


Unsuccessful attempt 


Stop trigger point not reached. 
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6.5.5 Streaming Service Access Time [s] 



6.5.5.1 Abstract Definition 

The parameter Streaming Service Access Time describes the duration of a service access from requesting the stream at 
the portal until the reception of the first stream data packet at the UE. 

The first data packet refers to RTP protocol. 

6.5.5.2 Abstract Equation 



Streaming Service Access Time [S] = (t,eceptionoffirstdatapacket -tstreamrequest)[s] 



6.5.5.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


Weam request ■ Time when Stream 
is requested 


Start: Stream request. 


Start: 

■ WAP 1.x, WAP 2.x: 
WSP Disconnect; 

WAP 2.x: TCP SYN towards streaming 
platform. 


deception of first data packet ■ "^^ 
when first data pacl<et is received 


Start: "Buffering" message. 


Stop: Reception of first data pacl<et. 



6.5.6 Streaming Reproduction Cut-off Ratio [%] 
6.5.6.1 Abstract Definition 

The parameter Streaming Reproduction Cut-off Ratio describes the probability that a successfully started stream 
reproduction is ended by a cause other than the intentional termination by the user. 



6.5.6.2 Abstract Equation 



Streaming Reproduction Cut - off Ratio [%] 



unintenionally terminated stream reproductions 
all successfully started stream reproductions 



xlOO% 



6.5.6.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


Successfully started media 
streaming reproduction 


Start: Stream reproduction starts. 


Start: Streaming player signals the start of the 
stream reproduction. 


Intentional terminated streaming 
reproduction 


Stop: User presses the "Exit" 
button or end of stream is reached. 


Stop: RTSP Teardown method sent by UE and 
reception of confirmation "RTSP 200 OK" from 
media server. 


Unintentional terminated 
streaming reproduction 


Stop trigger point not reached. 



NOTE: Not all players may signal the reproduction start. 

Some players do not send this TEARDOWN command at the end of the stream but a PAUSE command or in some 
cases nothing at all. On the server side a logic can then identify the status of the streams/clients. 

Used players should send the RTSP:TEARDOWN command in order to give a stable trigger point for measurements. 
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6.5.7 Streaming Audio Quality 

6.5.7.1 Abstract Definition 

The parameter Streaming Audio Quality describes the audio quality as perceived by the end-user. Since the streams can 
contain and not only speech information, an algorithm like P. 862 is not suitable for all scenarios. 

ITU-R has defined an algorithm defined for audio information. It can be found in [6]. 

6.5.7.2 Abstract Equation 

To be defined. 

6.5.7.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


Tbd 


Start: Begin of audio stream 
reproduction. 


start: Streaming players signal when the 
reproduction of the stream starts. 


Tbd 


stop: End of audio stream 
reproduction. 


Stop: RTSP: TEARDOWN. 



6.5.8 Streaming Video Quality 



6.5.8.1 Abstract Definition 

The parameter Streaming Video Quality measures the quality of the video stream. 

NOTE 1 : Although evaluation algorithms exist, there are no standardized solutions yet. 

NOTE 2: Standardization process of evaluation algorithms is on-going and new recommendations are expected 
during the ITU study period 2005-2008. 

6.5.8.2 Abstract Equation 

NOTE 1 : Although evaluation algorithms exist, there are no standardized solutions yet. 

NOTE 2: Standardization process of evaluation algorithms is on-going and new recommendations are expected 
during the ITU study period 2005-2008. 

6.5.8.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


Tbd 


Start: Begin of video stream 
reproduction. 


Start: Streaming players signal when the 
reproduction of the stream starts. 


Tbd 


Stop: End of video stream 
reproduction. 


Stop: RTSP: TEARDOWN. 
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6.5.9 Streaming Audio/Video De-Synchronization 

6.5.9.1 Abstract Definition 

The parameter Streaming Audio/Video De-Synchronization describes the percentage of times that time difference of the 
audio and video signal at the user side exceeds a predefined threshold. 

6.5.9.2 Abstract Equation 

No validated or standardized algorithm has been selected for the evaluation for video streaming content quality. 

6.5.9.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


Tbd 


Start: Begin of audio stream 
reproduction. 


start: Streaming players signal when the 
reproduction of the stream starts. 


Tbd 


stop: End of audio stream 
reproduction. 


Stop: RTSP: TEARDOWN. 



6.5.10 Streaming Reproduction Start Failure Ratio [%] 
6.5.10.1 Abstract Definition 

The parameter Streaming Reproduction Start Failure Ratio describes the probability of unsuccessful stream 
reproduction. 

NOTE: This parameter can be affected: 

■ by the player; 

■ by the UE performance. 



6.5.10.2 Abstract Equation 



Streaming Reproduction Start Failure Ratio [%] 



reproduction failures 
all successful service accesses 



-xlOO% 



6.5.10.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


Service access attempt 


Start: "Buffering" message. 


Start: Reception of first data packet. 


Successful reproduction 


Stop: Stream reproduction. 


Stop: Streaming players signal when the 
reproduction of the stream starts. 


Unsuccessful reproduction 


Stop trigger point not reached. 



£75/ 



91 



ETSI TS 102 250-2 VI .5.1 (2007-10) 



6.5.1 1 Streaming Reproduction Start Delay [s] 
6.5.1 1 .1 Abstract Definition 

The parameter Streaming Reproduction Delay describes the duration between the reception at UE of the first stream 
data packet and the start of the reproduction of the stream on the UE. 

NOTE: This parameter can be affected: 

■ by the player; 

■ by the UE performance. 



6.5.1 1 .2 Abstract Equation 



Streaming Reproduction Start Delay [s] = (t 



start of stream reproduction reception of first data packet 



t)[s] 



6.5.11.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


deception of first data packet 


Start: "Buffering" message. 


Start: Reception of first data packet. 


^start of stream reproduction 


stop: stream reproduction. 


Stop: Streaming players signal when the 
reproduction of the stream starts. 



6.6 Telephony 

6.6.1 Telephony Service Non-Accessibility [%] 
6.6.1.1 Abstract Definition 

Probability that the end-customer cannot access the Mobile Telephony Service when requested if it is offered by display 
of the network indicator on the mobile equipment. 

NOTE: Due to network problems and despite B-party being not busy (see preconditions for measurement), it may 
even be possible for the A-party to receive a busy or not reachable signal. In this case, since no 
ALERTING message will be sent, the test sample will be treated as a failure. 



6.6.1.2 Abstract Equation 



Telephony Service Non - Accessibility [%] = ^— xlOO % 

all call attempts 
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6.6.1.3 Trigger Points 



Event from abstract 
equation 


Trigger point from customer's point 
of view 


Technical description / protocol part 


Call attempt 


Start: Push Send button. 


Start: The first RRC CONNECTION REQUEST with 
Establishment Cause "Originating Conversational Call" 
message carried on the CCCH logical channel and 
mapped to the RACH transport channel is sent, 
(figure 23; signalling point number 1). 

Comment: It is possible that more than one RRC 
CONNECTION REQUEST message per call attempt is 
sent. Only the first RRC CONNECTION REQUEST with 
Establishment Cause "Originating Conversational Call" 
should be taken into account for the calculation. 

It is possible that the RRC connection is already 
established because of an e.g. Location Update, then 
the start trigger is not reachable. In this case the 
current test sample should be deleted. 


Successful call 
attempt 


Stop: Alerting tone is heard by the 
A-party coming from B-party 

AND 

B-party rings. 


Stop: The ALERTING message on the DCCH logical 
channel is passed: 

1 . from the B-party to the IVISC (uplink) 
AND 

2. from the MSC to the A-party (downlink) to 
indicate that the A-party rings. 

(Figure 2; signalling point number 4). 


Unsuccessful call 
attempt 


Stop trigger point not reached. 


NOTE: With automatic tools there is not a significant difference between consider the alerting or the connect 
message, as the answer machine should always answer immediately. 



Preconditions for measurement: 



Precondition 


Covered by 


Reference document 


CS network available 


Radio Network Unavailability 




CS attach successful 






B-party shall not be busy 







UE 



Node B 



. RACH: CCCH: RRC CONNECTION REQUEST <TM> 



RNC 





2. RADIO LINK SETUP REQUEST 



3. RADIO LINK SETUP RESPONSE 



. ESTABLISH REQUEST (AAL2) 



5. ESTABLISH CONFIRM (AAL2) 



6. DOWNLINK SYNCHRONISATION 



7. UPLINK SYNCHRONISATION 






8. EACH: CCCH: RRC CONNECTION SETUP <UM> 



9. INSYNCH IND 




10. RADIO LINK RESTORE INDICATION . 




11. DCCH: RRC CONNECTION SETUP COMPLETE <AM> 




MSC / VLR 
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UE 





NodeB 



T 



12. DCCH: INITIAL DT [ CM SERVICE REQUEST ] <AM> 



17. DCCH: SECURITY MODE COMMAND <AM> 



18. DCCH: SECURITY MODE COMPLETE <AM> 



21 . DCCH: DLDT [ IDENTITY REQUEST ] <AM> (IMEl) 



22. DCCH: ULDT [ IDENTITY RESPONSE ] <AM> (IMEl) 



24. DCCH: ULDT [ ] <AM> 



28. DCCH: DLDT [ CALL PROCEEDING ] <AM> 



RNC 



MSC/VLR 



13. SCCP CONNECTION RQ [ 

INITIAL UE MESSAGE 
[ CM SERVICE REQUEST ] ] 



14. SCCP CONNECTION 
CONFIRM 



15. COMMON ID 




16. SECURITY MODE COMMAND 
' RANAP >^ ' C RANAP ^ 



1 9. SECURITY MODE COMPLETE 
f RANAP ") -— ►<f RANAP ]; 





25. DT[ SETUP] 



►(^RANAP^ 



27. DT [ CALL PROCEEDING ] 
' RANAP >< C RANAP^ 



MGW 



26. INITIAL DP 



UE 



C]^RRC^^><- 




NodeB 



RNC 



^ALCAPJ>^- 

33. RADIO LINK RECONFIG PREPARE 
NBAP JH C NBAP 

34. RADIO LINK RECONFIG READY 
' NBAP ") ■ ►(^ NBAP ~ 

35. ESTABLISH REQUEST (AAL2) 
36. ESTABLISH GCMMFIRM (AAL2) 



37. RADIO LINK RECONFIG COMMIT 




38. DCCH: RADIO BEARER SETUP <AM> 



MSC/VLR 



30. RAB ASSIGNMENT REQUEST 



MGW 



29. BINDING ID, SPEECH 
CODEC TYPE, B PARTY 
^ ROUTE _, 



-([RANAP^ 



31 . ESTABLISH REQUEST ( AAL2 ) 



32. ESTABLISH CONFIRM ( AAL2 



40. DCCH: RADIO BEARER SETUP COMPLETE <AM> 



44. DCCH: DLDT [ ALERTING J <AM> 



47. DCCH: DLDT [ CONNECT ] <AM> 



49. DCCH: ULDT [ 




43. DT [ ALERTING ] 



50. DT [ CONNECT ACK ] 



-►Qalcapj; 

(fALCAP^ 




ETSI 



94 



ETSI TS 102 250-2 V1.5.1 (2007-10) 



UE 



NodeB 




UE 



(^[^Rro^ 



51 . DCCH; ULDT [ DISCONNEC T ] <AM> 



55. DCCH: DLDT [ RELEASE ] <AM> 



56. DCCH; ULDT [ RELEASE COMPLETE ] <AM> 



60. DCCH; RADIO BEARER RELEASE <UM> 



64. DCCH; RADIO BEARER RELEASE COMPLETE <UM> 



65. DCCH; RRC CONNECTION RELEASE <UM> 



NodeB 



I DCCH: RRC CONNECTION RELEASE COMPLETE <UM> 



72. RADIO LINK DELETION RESPONSE 
NBAP ^ ►(' NBAP 



73. RELEASE REQUEST( AAL2 ) 
' ALCAP >< C ALCAP 



74. RELEASE REQUEST ( AAL2 ) 
' ALCAP y^ ( ALCAP 



75. RELEASE CONFIRM ( AAL2 ) 
f ALCAP 'y ■ kT ALCAP 



76. RELEASE CONFIRM ( AAL2 ) 
' ALCAP ") ' ►(" ALCAP 




Figure 23: 3G Voice Signalling Flow Chart: Mobile Originated Call Establishment Procedure 
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6.6.2 Telephony Setup Time [s] 

6.6.2.1 Abstract Definition 

Time between sending of complete address information and receipt of call set-up notification. 

6.6.2.2 Abstract Equation 



TelephonySetupTime[s] = (t_„_,,.,.,Kn„H^ -t 



connect established customer presses send button on UE 



)[S] 



t2: point of time where connect is established (e.g. alerting or subscriber busy is detected by test equipment), 
see note. 

t^: point of time where the customer presses the send button on mobile equipment. 

NOTE: If you do not establish an end-to-end connection afterwards you must ignore this measurement. It is 
assumed that early traffic channel assignment is used. 

6.6.2.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


^customer presses send button on UE ■ 
Time of call attempt 


Start: Push send button. 


Start: The first RRC CONNECTION REQUEST 
with Establishment Cause "Originating 
Conversational Call" message carried on the 
CCCH logical channel and mapped to the 
RACH transport channel is sent. 
(Figure 2; signalling point number 1). 

Comment: It is possible that more than one 
RRC CONNECTION REQUEST message per 
call attempt is sent. Only the first RRC 
CONNECTION REQUEST with Establishment 
Cause "Originating Conversational Call" should 
be taken into account for the calculation. 

It is possible that the RRC connection is already 
established because of an e.g. Location 
Update, then the start trigger is not reachable. 
In this case the current test sample should be 
deleted. 


^connection established ■ Time when 
connection is established 
(successful call attempt) 


stop: Alerting tone is heard by the 
A-party coming from the B-party 

AND 

B-party rings. 


Stop: The ALERTING message on the DCCH 
logical channel is passed: 

1 . from the B-party to the MSC (uplink) 
AND 

2. from the MSC to the A-party (downlink) 
to indicate that the A-party rings. 

(Figure 2; signalling point number 44). 


NOTE: With automatic tools there is not a significant difference between consider the alerting or the connect 
message, as the answer machine should always answer immediately. 



Preconditions for measurement: 



Precondition 


Covered by 


Reference document 


CS network available 


Radio Network Unavailability 




CS attach successful 






CS service access successful 


Telephony Service Non-Accessibility 





£75/ 



96 ETSI TS 1 02 250-2 V1 .5.1 (2007-1 0) 

6.6.3 Telephony Speech Quality on Call Basis 

6.6.3.1 Abstract Definition 

Indicator representing the quantification of the end-to-end speech transmission quality of the Mobile Telephony 
Service. This parameter computes the speech quality on the basis of completed calls. 

6.6.3.2 Abstract Equation 

The validation of the end-to-end quality is made using the MOS_Lgo scale. This scale describes the opinion of 
customers with voice transmission and its troubles (noise, robot voice, echo, dropouts etc). The speech quality 
measurement is taken per call. An aggregation should be made on one value for speech quality per call. 

Reference: ITU-T Recommendation P. 862 [1] in conjunction with ITU-T Recommendation P. 862.1 [9]. 



Telephony Speech Quality on Call Basis (received A - party) = f (MOS - LQO) 
Telephony Speech Quality on Call Basis (received B - party) = f (mOS - LQO) 



Optionally it might be useful to aggregate both speech quality values into one. In this case the worst of both shall be 
used. This aggregated speech quahty value shall be called SpQ (min). 

6.6.3.3 Trigger Points 

NOTE: The acoustic behaviour of terminals is not part of this speech quality measurement. 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


Not applicable. 


Start: Interchange speech samples 
between A-party and B-party. 


Start: A CONNECT message on the DCCH 
logical channel is passed from the MSC to the 
UE to indicate that the called user's end has 
been connected. 
(Figure 2; signalling point number 47). 


Not applicable. 


Stop: Release of connection. 


Stop: A DISCONNECT message on the DCCH 
logical channel is sent from the UE (message 
sent when the user ends the call). 
(Figure 2; signalling point number 51). 



6.6.4 Telephony Speech Quality on Sample Basis 

6.6.4.1 Abstract Definition 

Indicator representing the quantification of the end-to-end speech transmission quality of the Mobile Telephony 
Service. This parameter computes the speech quality on a sample basis. 

6.6.4.2 Abstract Equation 

The validation of the end-to-end quality is made using the MOS scale. This scale describes the opinion of customers 
with voice transmission and its troubles (noise, robot voice, echo, dropouts etc). The speech quality measurement is 
taken per sample. An aggregation for measurement campaigns or parts of it should be made on speech sample basis. 

NOTE: Reference: ITU-T Recommendation P.862 [1] in conjunction with ITU-T Recommendation P.862.1 [9]. 



Telephony Speech Quality on Sample Basis (received A - party) = f (MOS - LQO) 
Telephony Speech Quality on Sample Basis (received B - party) = f (MOS - LQO) 



Optionally it might be useful to aggregate both speech quality values into one. In this case the worst of both shall be 
used. This aggregated speech quality value shall be called SpQ (min). 



£75/ 



97 



ETSI TS 102 250-2 V1.5.1 (2007-10) 



6.6.4.3 Trigger Points 

The same as for Speech QuaHty on call basis (see clause 4.3.3.2). 

NOTE: The acoustic behaviour of terminals is not part of this speech quality measurement. 

6.6.5 Telephony Cut-off Call Ratio [%] 
6.6.5.1 Abstract Definition 

Probability that a successful call attempt is ended by a cause other than the intentional termination by 
A- or B-party. 



6.6.5.2 Abstract Equation 



^ , . ^ ^^„ „„ . n^, unintentionally terminated telephony calls , „„ ^ 

Telephony Cut - off Call Ratio [%] = ^- ^ ^- x 1 00 % 

all successful telephony call attempts 



6.6.5.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


Successful telephony call attempt 


Start: Alerting or busy tone heard 
by the A-party coming from 
B-party. 


Start: The CONNECT message on the DCCH 
logical channel is passed from the MSC to the 
UE to indicate that the connection has been 
established. 

(Figure 2; signalling point number 47). 
NOTE:With automatic tools there is not a 
significant difference between consider the 
alerting or the connect message, as the answer 
machine should always answer immediately. 


Intentionally terminated 
telephony call 


stop: Release of connection 
directly by A- or B-party. 


Stop: A DISCONNECT message on the DCCH 
logical channel is sent from the UE (message 
sent when the user ends the call). 
(Figure 2; signalling point number 51). 


Unintentionally terminated 
telephony call 


Stop trigger point not reached. 



6.7 Video Telephony 

6.7.1 Network Accessibility/ Availability 

Network availability and network accessibility are measured independently from the service, and will not be described 
further in this clause. Network availability and network accessibility are pre-conditions for the performance of the 
measurement of QoS. 
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6.7.2 Parameter Overview Chart 



To get a better overview of the following parameters, figure 24 shows all steps of a Video Telephony call from origin to 
destination, and the related QoS parameters. 

Preconditions for the measurements: It should be a bi-directional Video Telephony call. Both sides should allow the 
transmission of both audio and video. 

Explanation: The upper half considers the trigger points and parameters at the originated side and the lower half at the 
terminated side. The rectangles are connected to the trigger points that are relevant for analysis. For example: "t3, orig. 
side" (triggerpoint at originated side) and "t3, term, side" (triggerpoint at terminated side) are points of time that 
describe a similar event but it could be passed at slightly different times. The preconditions are specified in brackets 
behind the parameter name. The technical triggers are defined for positive successful cases, if the VT works fine. For 
failures the triggers are the opposite, this means the non-existence of the message indicates the failure. The bold lines 
behind the trigger points tx are the used one and the dashed one are unused. 
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VT Cut-off Call Ratio [%] , (Precond.: Service Access) 



mobile 
originated side 



trigger points 

customer's 

view 



techinical 

trigger points 

for success 

cases 



VT Service Access 

Tirre [s] , (Precond.: 

Service Access) 

presses connect 
button (originated 
side) 



RRC CONNECTION 
REQUEST message 
(CCCH ) 

10, prig, side 






trigger points 
customer's 




hears a) alerting or b) 
busy tone 



ALERTING (DCCH), 

(between 

RNC>UE(MO)) 

11, orlg. side 



11, term, side 

ALERTING (DCCH), 

(between 

UE(MT)>RNC) 



VT Audio/Video Sifup 

Failure Ratio [%] , 

(Precond.: Service 

Access) 



VT Audio/Video Setupl 

Time [s] , (Precond 

Service Access) 



seeing call accept 



CONNECT message 
(DCCH ), (between 
RNC>UE(MO)) 

12, term, side 



fiears mobile ringing 
tone (in case of a) s. 
originated) 



12, term, side 

ICONNECT message 
|(DCCH ), (between 
,UE(MT)>RNC) 

lacceptlng caii 
■(terminated side) 



VT Audio/Video Setupl 

Time [s] , (Precond 

Service Access) 



sees/hears 
established 
video/audio 



reception of audio and 
video data from ttie 
ottier side 

13, prig, side 



VT End-To-End Mean 

One-Way 

Transmission Time [s] 

, (Precond.: A/V 

audio / video data 
UPLINK 



t3, term, side 



reception of audio and 
video data from the 
other side 




sees/hears 
established 
video/audio 



audio / video data 
UPLINK 

VT End-To-End Mean 

One-Way 

Transmission Time [s] 

, (Precond.: A/V 



VT Audio/Video Setup| 
Failure Ratio [%] , 
(Precond.: Service 

1: Access) ^ 



VT Cut-off Call Ratio [%] , (Precond.: Service Access) 

Figure 24: Parameter overview with trigger points 



VT Audio Ouailty 

[MOS-LQO] , 

(Precond.: A/V Setup) 



VT Video Quality , 

(Precond.: Call 

Setup), (Precond.: 

A/V Setup) 



VT Audio/Video Sync. 

[%], (Precond.: A/V 

Setup) 



audio / video data 
DOWNLINK 



continuous reception 
of audio and video 
data at both sides 
from the opposite side 



15, orlg. side 



15, term, side 
continuous reception 
of audio and video 
data at both sides 
from the opposite side 



audio / video data 
DOWNLINK 



VT Audio/Video Sync. 

[%] , (Precond.: A/V 

Setup) 



VT Video Quality , 
(Precond.: A/V Setup) 



VT Audio Ouailty 

[MOS-LQO] , 

(Precond.: A/V Setup) 



Intentional 



continuous reception 
of audio and video 
until Int. termination 

tSa, orig. side 



16a, term, side 

continuous reception 
of audio and video 
until Int. termination 



Intentional 



termination 



END 
SESSiO 
N (H.245) 

16b, orig. side 



END 
SESSiO 
N (H.245) 



termination 



of caii 



if MO releases the 
call: DISCONNECT, 
RELEASE 
combination 
16c, orlg. side 



:j 



t6b, term. slde|16c, term, side 

If MT releases the 
call: DISCONNECT, 
RELEASE 
combination 



of caii 
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6.7.3 VT Service Non-Accessibility [%] 

6.7.3.1 Abstract Definition 

Probability that the end-customer cannot access the service when requested while it is offered by network indication on 
the mobile equipment. 

NOTE: Due to network problems and despite MO side being not busy (see preconditions for measurement), it 
may even be possible for the MO side to receive a busy or not reachable signal. In this case, since no 
ALERTING message will be sent, the test sample will be treated as a failure. 

6.7.3.2 Abstract Equation 



VT Service Non - Accessibility [%] 



unsuccessfLil video telephony call access attempts 
all video telephony call access attempts 



xlOO% 



6.7.3.3 Trigger Points 



Event from abstract 
equation 


Trigger point from customer's point 
of view 


Technical description / protocol part 


Video Telephony call 
attempt 


Start: Push Send button. 


Start: The first RRC CONNECTION REQUEST with 
Establishment Cause ..originating conversational call 
message carried on the CCCH logical channel and 
mapped to the RACH transport channel is sent, 
(clause 6.7.13, signalling point number 1) 

Comment: It is possible that more than one RRC 
CONNECTION REQUEST message per call attempt is 
sent. Only the first RRC CONNECTION REQUEST with 
Establishment Cause ..Originating Conversational Call 
should be taken into account for the calculation. 

It is possible that the RRC connection is already 
established because of an e.g. Location Update, then the 
start trigger is not reachable. In this case the current test 
sample should be deleted. 


Successful Video 
Telephony call attempt 


Stop: Alerting tone is heard by the IVIO 
side coming from the IVIT side 

AND 

IVIT side rings. 


Stop: The ALERTING message on the DCCH logical 
channel is passed: 

1 . from the UE at IVIT side to IVISC (uplink) 
AND 

2. from the MSC to the UE at IVIO side (downlink) to 
indicate that the MT side rings. 

(clause 6.7.1 3, signalling point number 44) 


Unsuccessful Video 
Telephony call attempt 


Stop trigger point not reached. 


Stop trigger point not reached. 



Preconditions for measurement: 



Precondition 


Covered by 


Reference document 


UMTS CS available 


Radio Network Unavailability 




UMTS CS attach successful 






MT side shall not be busy 
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6.7.4 VT Service Access Time [s] 
6.7.4.1 Abstract Definition 

Time between pushing send button after input of MSISDN and receipt of alerting at MO side. 

Remark: 

• This parameter is not calculated unless the video telephony call access attempt is successful. At MX side the 
mobile shall ring. 



6.7.4.2 Abstract Equation 



VT Service Access Time [s] = (t 



alerting tone push send button 



)[S] 



6.7.4.3 Trigger Points 



Event from abstract 
equation 


Trigger point from customer's point 
of view 


Technical description / protocol part 


*push send button ■ "'"''^^ 
of Video Telephony 
call attempt 


Start: Push Send button. 


Start: The first RRC CONNECTION REQUEST with 
Establishment Cause ..originating conversational call 
message carried on the CCCH logical channel and 
mapped to the RACH transport channel is sent, 
(clause 6.7.13, signalling point number 1) 

Comment: It's possible that more than one RRC 
CONNECTION REOUEST message per call attempt is 
sent. Only the first RRC CONNECTION REOUEST with 
Establishment Cause ..Originating Conversational Call 
should be taken into account for the calculation. 

It is possible that the RRC connection is already 
established because of an e.g. Location Update, then the 
start trigger is not reachable. In this case the current test 
sample should be deleted. 


*alerting tone : Time of 

successful Video 
Telephony call attempt 


Stop: Alerting tone is heard by the IVIO 
side coming from the MT side 

AND 

MT side rings. 


Stop: The ALERTING message on the DCCH logical 
channel is passed: 

1 . from the UE at IVIT side to IVISC (uplink) 
AND 

2. from the IVISC to the UE at MO side (downlink) to 
indicate that the MT side rings. 

(clause 6.7.1 3, signalling point number 44) 



Preconditions for measurement: 



Precondition 


Covered by 


Reference document 


UMTS CS available 


Radio Network Unavailability 




UMTS CS attach successful 






UMST CS service access 


VT Service Access Failure Ratio 





6.7.5 VT Audio/Video Setup Failure Ratio [%] 
6.7.5.1 Abstract Definition 

Probability of audio/video setup failure after service access. The audio/video setup is successful if audio and video 
output is performed at both sides. 



Remarks: 



This parameter reports a failure if the end-trigger is not reached at both sides. 
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This parameter is not calculated unless the VT service access attempt is successful. 

This parameter depends on the mobile used and on the multimedia protocol stack implemented (e.g. answer 
fast feature). 



6.7.5.2 Abstract Equation 



^.r^ . ,.„,., „ ^ .. „ . n^n audio/video setup failures , ^„ „ 

VT Audio/Video Setup Failure Ratio [%] = xlOO % 

all accepted calls at MT side 



6.7.5.3 Trigger Points 



Event from abstract 
equation 


Trigger point from customer's point 
of view 


Technical description / protocol part 


Audio/video setup 
attempt 


Start: MO sees the call acceptance 
from the MT side. 


Start: The CONNECT message on the DCCH logical 
channel is passed from the MSC to the UE at MO side to 
indicate that the connection has been established, 
(clause 6.7.1 3, signalling point number 47) 


Audio/Video Setup 
Success 


Stop: Start of the audio and video 
output at both sides. 


Stop: Start of reception of audio and video data at both 
sides from the opposite side. 

Comment: All four data streams shall be received for a 
success. 


Audio/Video Setup 
Failure 


Stop trigger point not reached. 


Stop trigger point not reached. 



Preconditions of measurement: 



Precondition 


Covered by 


Reference document 


UMTS CS available 


Radio Network Unavailability 




UMTS CS attach successful 






UMTS CS service access 
successful 


VT Service Non-Accessibility 





6.7.6 VT Audio/Video Setup Time [s] 



6.7.6.1 Abstract Definition 

The elapsed time from the MT call acceptance indicated at MO side until audio and video output starts at both sides. 
Remarks: 

• This parameter should report the worse time of both sides. 

• This parameter is not calculated unless the VT audio/video setup attempt is successful. 

• This parameter depends on the mobile used and on the multimedia protocol stack implemented (e.g. answer 
fast feature). 



6.7.6.2 Abstract Equation 



VTAudioA^ideo Setup Time [s] = (t 



audio/video start MT accepts call 



i)[s] 
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6.7.6.3 Trigger Points 



Event from abstract 
equation 


Trigger point from customer's point 
of view 


Technical description / protocol part 


tMTacceptscairTimeof 
beginning of audio / 
video setup 


Start: IVIO sees the call acceptance 
from the MT side. 


Start: The CONNECT message on the DCCH logical 
channel is passed from the IVISC to the UE at MO side to 
indicate that the connection has been established, 
(clause 6.7.1 3, signalling point number 47) 


*audio/video start ■ "'"''^^ 
of successful audio / 
video setup 


Stop: Start of the audio and video 
output at both sides. 


Stop: Start of reception of audio and video data at both 
sides from the opposite side + constant time value for 
decoding. 

Comment: All four data streams shall be received for a 
success. 



Preconditions for measurement: 



Precondition 


Covered by 


Reference document 


UMTS CS available 


Radio Network Unavailability 




UMTS CS attach successful 






UMTS CS audio/video setup successful 


VT Audio/Video Setup Failure 
Ratio 





6.7.7 VT Cut-off Call Ratio [%] 

6.7.7.1 Abstract Definition 

Probability that a successful service access is ended by a cause other than the intentional termination of the user (calling 
or called party). 

Remark: 

• This parameter is not calculated unless the VT service access attempt is successful. A VT call is considered 
dropped: 

if the call acceptance fails after alerting; 

if audio/video setup fails; or 

if either the audio, the video or both are lost at one or both sides for an interruption timeout and before 
the end of "predefined call duration". 

The "predefined call duration" is the difference between the indication of the call acceptance at MO side and the 
intentional release of the call. 

6.7.7.2 Abstract Equation 



VT Cut -off Call Ratio [%]: 



video telephony dropped calls 



all successful video telephony service access attempts 



-xlOO% 
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6.7.7.3 Trigger Points 



Event from abstract 
equation 


Trigger point from customer's point 
of view 


Technical description / protocol part 


Successful Video 
Telephony service 
access attempt 


Start: Alerting tone is heard by the MO 
side coming from MT side 

AND 

MT side rings. 


Start: The ALERTING message on the DCCH logical 
channel is passed: 

1 . from the UE at MT side to MSC (uplink) 
AND 

2. from the MSC to the UE at MO side (downlink) to 
indicate that the MT side rings. 

(clause 6.7.13, signalling point number 1) 


Video Telephony 
successful call 


Stop: No loss of video and/or audio 
without any intention by MO or MT side 
longer than the interruption timeout 
within the predefined call duration. 


Stop: 

1 . If the test system can capture audio / video 
information: 

Continuous reception of audio and video data at both 
sides from the opposite side without an interruption 
longer than the interruption timeout until intentional call 
release. 

2. If the test system cannot capture audio / video 
information: 

The following information shall not be seen in signalling 
before intentional call release but they shall be seen after 
the intentional call release: 

• H.245 EndSession command 
(endSessionCommand disconnect) 
OR 

• the following trigger combination (all triggers on 
the DCCH logical channel): 

[M1: DISCONNECT (uplink).] 
AND 

[M2: DISCONNECT (downlink) or RELEASE 
(downlink)] 
(clause 6.7.13, signalling point number 51) 

Comment: In some cases the mobiles use not the 
EndSession command but only the DISCONNECT or 
RELEASE command. 


Video Telephony 
dropped calls 


Stop trigger point not reached. 


Stop trigger point not reached. 



NOTE: If the reception of audio and/or video is interrupted shortly before the predefined call duration, then the 
call duration shall be extended to check if the interruption persists for the interruption timeout or not. If 
the interruption is shorter than the interruption timeout the call shall be released immediately and rated as 
success otherwise the sample shall be rated as failure and the call will be released. 

Preconditions for measurement: 



Precondition 


Covered by 


Reference document 


UMTS CS available 


Radio Network Unavailability 




UMTS CS attach successful 






UMTS CS service access successful 


VT Service Non-Accessibility 
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6.7.8 VT Speech Quality on Call Basis [MOS-LQO] 

6.7.8.1 Abstract Definition 

Indicator representing the quantification of the end-to-end speech transmission quality of the Video Telephony service. 
This parameter computes the speech quality on the basis of completed calls. 

Remarks: 

• This parameter is not calculated unless the VT audio/video setup attempt is successful. 

• The speech quality measurement is taken per call. An aggregation for measurement campaigns or parts of it 
should be made on speech sample basis. 

• The acoustic behaviour of terminals is not part of this audio quality measurement. The modelling of the 
acoustic part of the handset-terminals (e.g. frequency shaping) is incorporated in the speech quality assessment 
algorithm. Therefore the test mobiles used have to be connected at their electrical interfaces and not coupled 
acoustically, it has to be taken into account that a detailed way for insertion and capturing of audio signals is 
described in ITU-T Recommendation P. 862.3 [19]. 

• For wideband (7 kHz) applications a standardized algorithm is available in ITU-T Recommendation 
P.862.2 [18]. 

• Evaluation of a MO DL or MT DL and also for these both directions (sum) is possible by calculating the mean 
value of the results from all samples. 

• Experience has shown a high variable delay in video calls. 

• ITU-T Recommendation P. 862 [1] is not approved for testing such video call applications. It has to be taken 
into account that further studies including auditory tests of video calls have to be conducted. 

6.7.8.2 Abstract Equation 

ITU-T Recommendation P. 862 [1] (02/2001) together with the related mapping given in ITU-T Recommendation 
P. 862.1 [9] (10/2003) is recommended. This algorithm describes the opinion of customers related to voice transmission 
quality (300 through 3400 Hz) and its connected impairments (background noise, unnatural voice, temporal clipping 
and interruptions etc). 

The speech quality measurement is taken per call (the evaluation algorithm is currently under study in ETSI STQ 
MOBILE WG) and per direction (DL at MO, DL at MT). 

After mapping the raw P. 862 results according to ITU-T Recommendation P. 862. 1, the speech quality assessment is 
presented in a MOS-like scale between 1 and 5 called MOS Listening Quality Objective (MOS-LQO), as defined in 
ITU-T Recommendation P.800.1 [23]. 



6.7.8.3 Trigger Points 



Event from abstract 
equation 


Trigger point from customer's point 
of view 


Technical description / protocol part 


Successful 
Audio/Video Setup 
Attempt 


start: Start of the audio and video 
output at both sides. 


Start: Start of reception of audio and video data at both 
sides from the opposite side. 

Comment: All four data streams shall be received for a 
success. 


End of call (only 
intentional) 


Stop: End of call. 


Stop: 

End of continuous reception of audio and video data at 
both sides from the opposite side because of: 
• intentional call release. 
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Preconditions for measurement: 



Precondition 


Covered by 


Reference document 


UMTS CS available 


Radio Network Unavailability 




UMTS CS attach successful 






UMTS CS service access successful 


VT Service Non-Accessibility 




UMTS CS audio/video setup successful 


VT Audio/Video Setup Failure Ratio 





6.7.9 VT Speech Quality on Sample Basis [MOS-LQO] 

6.7.9.1 Abstract Definition 

Indicator representing the quantification of the end-to-end speech transmission quality as perceived by the user. This 
parameter computes the speech quality on a sample basis. 

Remarks: 

• This parameter is not calculated unless the VT audio/video setup attempt is successful. 

• Speech quality values from all video telephony calls should be taken into consideration for statistical quality 
analysis. 

• The speech quality measurement is taken per sample. An aggregation for measurement campaigns or parts of it 
should be made on speech sample basis. Only complete received samples of a dropped call are evaluable. 

• The acoustic behaviour of terminals is not part of this audio quality measurement. The modelling of the 
acoustic part of the handset-terminals (e.g. frequency shaping) is incorporated in the speech quality assessment 
algorithm. Therefore the test mobiles used have to be connected at their electrical interfaces and not coupled 
acoustically, it has to be taken into account that a detailed way for insertion and capturing of audio signals is 
described in the new ITU-T Recommendation P.862.3 [19]. 

• For wideband (7 kHz) applications a standardized algorithm is available in ITU-T Recommendation 
P.862.2 [18]. 

• Evaluation of a MO DL or MT DL and also for these both directions (sum) is possible by calculating the mean 
value of the results from all samples. 

• Experience has shown a high variable delay in video calls. 

• P. 862 is not approved for testing such video call applications. It has to be taken into account that further 
studies including auditory tests of video calls have to be conducted. 

6.7.9.2 Abstract Equation 



f (speech Quality Assessment Algorithm, {x^ , ..., Xj, }, RL) = {yj , ..., y^, }[M0S - LQO] 



where: 

• Speech Quality Assessment Algorithm: algorithm applied. 

• {xi,...,Xn}: completed speech samples belonging to both completed and dropped calls. 

• {yi,...,yn}: results generated by the algorithm. 

• RL: Radio Link (DL at MO, DL at MT, sum). 

ITU-T Recommendation P. 862 [1] (02/2001) together with the related mapping given in ITU-T Recommendation 
P. 862.1 [9] (10/2003) is recommended. This algorithm describes the opinion of customers related to voice transmission 
quality (300 through 3400 Hz) and its connected impairments (background noise, unnatural voice, temporal clipping 
and interruptions etc). 

The speech quality measurement is taken per sample and per direction (DL at MO, DL at MT). 
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After mapping the raw P.862 results according to ITU-T Recommendation P.862.1 [9], the speech quality assessment is 
presented in a MOS-like scale between 1 and 5 called MOS Listening Quality Objective (MOS-LQO), as defined in 
ITU-T Recommendation P. 800.1 [23]. 

6.7.9.3 Trigger Points 



Event from abstract 
equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


Successful Audio/Video 
Setup Attempt 


Start: Start of the audio and video 
output at both sides. 


Start: Start of reception of audio and video data at both 
sides from the opposite side. 

Comment: All four data streams shall be received for a 
success. 


End of call (intentional 
or dropped) 


Stop: End of call. 


Stop: 

End of continuous reception of audio and video data at 

both sides from the opposite side because of: 

• an interruption for a predefined duration or 
longer 

OR 

• intentional call release. 



Preconditions for measurement: 



Precondition 


Covered by 


Reference document 


UMTS CS available 


Radio Network Unavailability 




UIVITS CS attach successful 


Attach Failure Ratio 




UIVITS CS service access successful 


VT Service Non-Accessibility 




UMTS CS audio/video setup successful 


VT Audio/Video Setup Failure Ratio 





6.7.10 VT Video Quality 

6.7.10.1 Abstract Definition 

End-to-end quality of the video signal as perceived by the end user during a VT call. This parameter computes the video 
quality on a sample basis. 

Remarks: 

• This parameter is not calculated unless the VT audio/video setup attempt is successful. 

• Video quality values from all video telephony calls should be taken into consideration for statistical quality 
analysis. 

• The video quality measurement is taken per sample. An aggregation for measurement campaigns or parts of it 
should be made on video sample basis. Only complete received samples of a dropped call are evaluable. 

• Evaluation of a MO DL or MT DL and also for these both directions (sum) is possible by calculating the mean 
value of the results from all samples. 

6.7.10.2 Abstract Equation 

To be specified. 
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6.7.10.3 Trigger Points 



Event from abstract 
equation 


Trigger point from customer's point 
of view 


Technical description / protocol part 


Successful 
audio/video setup 
attempt 


Start: Start of the audio and video 
output at both sides. 


Start: Start of reception of audio and video data at both 
sides from the opposite side. 

Comment: All four data streams shall be received for a 
success. 


End of call (intentional 
or dropped) 


Stop: End of call. 


Stop: 

End of continuous reception of audio and video data at 

both sides from the opposite side because of: 

• an interruption for a predefined duration or 
longer 

OR 

• intentional call release. 



Preconditions for measurement: 



Precondition 


Covered by 


Reference document 


UMTS CS available 


Radio Network Unavailability 




UIVITS CS attach successful 


Attach Failure Ratio 




UIVITS CS service access successful 


VT Service Non-Accessibility 




UMTS CS audio/video Setup successful 


VT Audio/Video Setup Failure Ratio 





6.7.1 1 VT End-To-End Mean One-Way Transmission Time [s] 

6.7.1 1 .1 Abstract Definition 

Delay time from input of the signal at MS (MO/MT) (mic/cam) to output of the signal at MS (MT/MO) 
(loudspeaker/display) . 

Remark: 

• This parameter is not calculated unless the VT audio/video setup attempt is successful. 

6.7.1 1 .2 Abstract Equation 

Time from input of the signal at MS (MO/MT) to output at MS (MT/MO). 

Aggregation Algorithm: ((Transmission Time MO ->MT) + (Transmission Time MT->MO))/2. 

In case of a symmetrical channel one party could be configured as loopback device. The other one can determine the 
double delay by correlating transmit and receive signal. The delay should be measured after the loopback at the top of 
the radio bearer. 

As the delay of the codec is almost constant for a specific mobile implementation, the codec delay could be considered 
by a mobile depending offset. In each direction one shall add the encoder and the decoder times. For the whole 
loopback one shall calculate the following times: 



MO>MT 


Encoding of audio / video (slowest is used) 


a 




Transmission of audio / video (slowest is used) 


b 




Decoding of audio / video (slowest is used) 


c 


MT>MO 


Encoding of audio / video (slowest is used) 


d 




Transmission of audio / video (slowest is used) 


e 




Decoding of audio / video (slowest is used) 


f 



VT End - to - End Mean One - Way Transmission Time [s] : 



a+b+c+d+e+f 



[s] 
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6.7.11.3 Trigger Points 



Event from abstract 
equation 


Trigger point from customer's point 
of view 


Technical description / protocol part 


Successful 
audio/video setup 
attempt 


Start: Start of the audio and video 
output at both sides. 


Start: Start of reception of audio and video data at both 
sides from the opposite side. 

Comment: All four data streams shall be received for a 
success. 


End of call (intentional 
or dropped) 


Stop: End of call. 


Stop: 

End of continuous reception of audio and video data at 

both sides from the opposite side because of: 

• an interruption for a predefined duration or 
longer 

OR 

• intentional call release. 



Preconditions for measurement: 



Precondition 


Covered by 


Reference document 


UMTS CS available 


Radio Network Unavailability 




UIVITS CS attach successful 


Attach Failure Ratio 




UIVITS CS service access successful 


VT Service Non-Accessibility 




UMTS CS audio/video Setup successful 


VT Audio/Video Setup Failure Ratio 





6.7.12 VT Audio/Video Synchronization [%] 

6.7.12.1 Abstract Definition 

Percentage of times that the time differences of the audio and video signal at the user side exceeds a predefined 
threshold. 

Remarks: 

• This parameter is not calculated unless the VT audio/video setup attempt is successful. 

• Only if audio and video use different bearers this indicator would reflect the behaviour of the network and the 
mobiles. 

6.7.12.2 Abstract Equation 

To be specified. 

6.7.12.3 Trigger Points 



Event from abstract 
equation 


Trigger point from customer's point 
of view 


Technical description / protocol part 


Successful 
audio/video setup 
attempt 


Start: Start of the audio and video 
output at both sides. 


Start: Start of reception of audio and video data at both 
sides from the opposite side. 

Comment: All four data streams shall be received for a 
success. 


End of call (intentional 
or dropped) 


Stop: End of call. 


Stop: 

End of continuous reception of audio and video data at 

both sides from the opposite side because of: 

• an interruption for a predefined duration or 
longer 

OR 

• intentional call release. 



£75/ 



110 



ETSI TS 102 250-2 VI .5.1 (2007-10) 



Preconditions for measurement: 



Precondition 


Covered by 


Reference document 


UMTS CS available 


Radio Network Unavailability 




UMTS CS attach successful 


Attach Failure Ratio 




UMTS CS service access successful 


VT Service Non-Accessibility 




UMTS CS audio/video Setup successful 


VT Audio/Video Setup Failure Ratio 





6.7.13 Signalling Diagrams 



These are the flow charts of a mobile originated call until the call release. The point of view is the MO side. 



UE 




Node B 



RNC 



. RACH: CCCH: RRC CONNECTION REQUEST <7M> 



2. RADIO LINK SETUP REQUEST 



3. RADIO LINK SETUP RESPONSE 



4. ESTABLISH REQUEST (AAL2) 



5. ESTABLISH CONFIRM (AAL2) 



6. DOWNLINK SYNCHRONISATION 



7. UPLINK SYNCHRONISATION 




MSC / VLR 




a. FACH: CCCH: RRC CONNECTION SETUP <UM> 



I. INSYNCH IND 




10. RADIO LINK RESTORE INDICATION . 



11. DCCH: RRC CONNECTION SETUP COMPLETE <:AM> 




MGW 



ETSi 



111 



ETSI TS 102 250-2 V1.5.1 (2007-10) 



UE 




Node B 



RNC 



. RACH: CCCH: RRC CONNECTION REQUEST <TM> 





2. RADIO LINK SETUP REOUEST 



3. RADIO LINK SETUP RESPONSE 



.. ESTABLISH REQUEST (AAL2) 



5. ESTABLISH CQNFIRM (AAL2) 



6. DQWNLINK SYNCHRQNISATION 



7. UPLINK SYNCHRONISATION 





;. EACH: CCCH: RRC CONNECTION SETUP <UM> 



9. INSYNCH IND 




. RADIO LINK RESTORE INDICATION , 



. DCCH: RRC CONNECTION SETUP COMPLETE <AM> 




MSC/ VLR 



MGW 



UE 





NodeB 



T 



12. DCCH: INITIAL DT [ CM SERVICE REQUEST ] <AM> 



17. DCCH: SECURITY MODE COMMAND <AM> 



18. DCCH: SECURITY MODE COMPLETE <AM> 



21 . DCCH: DLDT [ IDENTITY REQUEST ] <AM> (IMEI) 



22. DCCH: ULDT [ IDEWTITY RESPONSE ] <AM> (IMEI) 



24. DCCH: ULDT [ SETUP ] <AM> 



28. DCCH: DLDT [ CALL PROCEEDING ] <AM> 



RNC 



MSC / VLR 



13. SCCP CONNECTION RQ [ 

INITIAL UE MESSAGE 
[ CM SERVICE REQUEST ] ] 



14. SCCP CONNECTION 
CONFIRM 



15. COMMON ID 



16. SECURITY MODE COMMAND 



19. SECURITY MODE COMPLETE 



20. DT [ IDENTITY REQUEST ] (IMEI i 



J3. DT [ IDENTITY RESPONSE j (IMEI ) 





25. DT['-:ETIJP] 




27. DT t CALL PROCEEDING ] 



MGW 



26. INITIAL DP 
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UE 




UE 





33. RADIO LINK RECONFIG PREPARE 
^ NBAP ^ ( NBAP 

34. RADIO LINK RECONFIG READY 
' NBAP ~) ■ ►C NBAP 



36. ESTABLISH CONFIRM (AAL2) 
' ALCAP ') ►< ALCAP 



38. DCCH: RADIO BEARER SETUP <AM> 



40. DCCH: RADIO BEARER SETUP COMPLETE <AM> 



44. DCCH: DLDT [ ALERTING ] <AM> 



47. DCCH: DLDT [ CONNECT ] <AM> 



49. DCCH: ULDT [ CONNECT ACK ] <AM> 



NodeB 



51 . DCCH: ULDT [ DISCONNECT ] <AM> 



55. DCCH: DLDT [ RELEASE ] <AM> 



56. DCCH: ULDT [ RELEASE COMPLETE ] <AM> 



60. DCCH: RADIO BEARER RELEASE <UM> 



64. DCCH: RADIO BEARER RELEASE COMPLETE <UM> 



65. DCCH: RRC CONNECTION RELEASE <UM> 




Figure 25: Parameter overview with trigger points 
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6.8 Web Browsing (HTTP) 

6.8.1 HTTP Service Non-Accessibility [%] 
6.8.1.1 Abstract Definition 

The service non-accessibility ratio denotes the probabiHty that a subscriber cannot establish a PDP context and access 
the service successfully. 



6.8.1.2 Abstract Equation 



HTTP Service Non - Accessibility [%] = 

unsuccessful attempts to reach the point when content is received 
all attempts to reach the point when content is received 



xlOO% 



6.8.1.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


Service access attempt 


start: Customer initiates the 
service access. 


Start: AID command. 


Successful attempt 


Stop: First content is received. 


Stop Method A: Reception of the first data 
packet containing content. 

Stop IVIethod B: Sending of the first GET 
command. 


Unsuccessful attempt 


Stop trigger point not reached. 



Remark: 

• The PS bearer has to be active in the cell used by a subscriber (see clause 5.1) and the mobile station has to be 
attached (see clause 5.3). 

6.8.2 HTTP Setup Time [s] 
6.8.2.1 Abstract Definition 

The setup time describes the time period needed to access the service successfully, from starting the dial-up connection 
to the point of time when the content is sent or received. 



6.8.2.2 Abstract Equation 



HTTP Setup Time [s] = (t 



service access successful service access start 



J[s] 



£75/ 



114 



ETSI TS 102 250-2 VI .5.1 (2007-10) 



6.8.2.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


Wice access start: Time of service 
access attempt 


Start: Customer initiates the 
service access. 


Start: AID command. 


^service access successful ■ "^^ °^ 
successful service access 


Stop: First content is received. 


Stop IVIethod A: Reception of the first data 
pacl<et containing content. 

Stop IVIethod B: Sending of the first GET 
command. 



Remark: 

• The PS bearer has to be active in the cell used by a subscriber (see clause 5.1) and the mobile station has to be 
attached (see clause 5.3). 

6.8.3 HTTP IP-Service Access Failure Ratio [%] 
6.8.3.1 Abstract Definition 

The IP-service access ratio denotes the probability that a subscriber cannot establish an TCP/IP connection to the server 
of a service successfully. 



6.8.3.2 Abstract Equation 



HTTP IP - Service Access Failure Ratio [%] = 

unsuccessful attempts to establish an IP connection to the server 
all attempts to establish an IP connection to the server 



xlOO% 



6.8.3.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


IP-Service access attempt 


Start: Customer enters the URL 
and hits "Return". 


Start: First [SYN] sent. 


Successful attempt 


Stop: Web page download starts. 


Stop Method A: Reception of the first data 
packet containing content. 

Stop Method B: Sending of the first GET 
command. 


Unsuccessful attempt 


Stop trigger point not reached. 



Remark: 

• The PS bearer has to be active in the cell used by a subscriber (see clause 5.1) and the mobile station has to be 
attached (see clause 5.3) as well as the respective PDP context has to be activated (see clause 5.5). 

6.8.4 HTTP IP-Service Setup Time [s] 
6.8.4.1 Abstract Definition 

The IP-service setup time is the time period needed to establish an TCP/IP connection to the server of a service, from 
sending the initial query to a server to the point of time when the content is sent or received. 
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6.8.4.2 Abstract Equation 



HTTP IP - Service Setup Time [s] = (t 



IP-Service access successful IP-Service access start 



t)[s] 



6.8.4.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


V-Service access start ■ "'"''^^ °^ "^" 
Service access attempt 


Start: Customer enters the URL 
and hits "Return". 


Start: First [SYN] sent. 


V-Service access successful ■ '^™^ °^ 
successful IP-Service access 


Stop: Web page download starts. 


Stop Method A: Reception of the first data 
packet containing content. 

Stop IVIethod B: Sending of the first GET 
command. 



Remark: The PS bearer has to be active in the cell used by a subscriber (see clause 5.1) and the mobile station has to be 
attached (see clause 5.3) as well as the respective PDP context has to be activated (see clause 5.5). 

6.8.5 HTTP Session Failure Ratio [%] 
6.8.5.1 Abstract Definition 

The completed session ratio is the proportion of uncompleted sessions and sessions that were started successfully. 



6.8.5.2 Abstract Equation 



HTTP Session Failure Ratio [%] 



uncompleted sessions 
successfully started sessions 



-xlOO% 



6.8.5.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


Successfully started session 


Start: Customer enters the URL 
and hits "Return". 


Start: First [SYN] sent. 


Completed session 


Stop: The complete web page 
appears in the browser window. 


Stop: Reception of the last data packet 
containing content. 


Uncompleted session 


Stop trigger point not reached. 



Remark: 

• The PS bearer has to be active in the cell used by a subscriber (see clause 5.1) and the mobile station has to be 
attached (see clause 5.3) as well as the respective PDP context has to be activated (see clause 5.5). 

6.8.6 HTTP Session Time [s] 
6.8.6.1 Abstract Definition 

The session time is the time period needed to successfully complete a PS data session. 



6.8.6.2 Abstract Equation 



HTTP Session Time [s] = (t.essionend " t 



session start 



)[S] 
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6.8.6.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


^session start: Time of successfully 
started session 


Start: Customer enters the URL 
and hits "Return". 


Start: First [SYN] sent. 


Wssion end : Time when session 
completed 


Stop: The complete web page 
appears in the browser window. 


Stop: Reception of the last data packet 
containing content. 



Remark: 

• The PS bearer has to be active in the cell used by a subscriber (see clause 5.1) and the mobile station has to be 
attached (see clause 5.3) as well as the respective PDP context has to be activated (see clause 5.5). 

6.8.7 HTTP Mean Data Rate [kbit/s] 
6.8.7.1 Abstract Definition 

After a data link has been successfully established, this parameter describes the average data transfer rate measured 
throughout the entire connect time to the service. The data transfer shall be successfully terminated. The prerequisite for 
this parameter is network and service access. 



6.8.7.2 Abstract Equation 



HTTP Mean Data Rate [kbit/s] : 



user data transferred [kbit] 






data transfer complete data transfer start 



)[S 



6.8.7.3 Trigger Points 

The average throughput is measured from opening the data connection to the end of the successful transfer of the 
content (web page). 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


Wta transfer start : Time of 
successfully started data transfer 


Start: Web page download starts. 


Start Method A: Reception of the first data 
packet containing content. 

Start Method B: Sending of the first GET 
command. 


Wta transfer complete : Time when 
data transfer complete 


Stop: Web page download 
successfully completed. 


Stop: Reception of the last data packet 
containing content. 



Remark: 

• The mobile station is already attached (see clause 5.3), a PDP context is activated (see clause 5.5) and a 
service was accessed successfully (see Service Non-Accessibility). 

6.8.8 HTTP Data Transfer Cut-off Ratio [%] 
6.8.8.1 Abstract Definition 

The data transfer cut-off ratio is the proportion of incomplete data transfers and data transfers that were started 
successfully. 
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6.8.8.2 Abstract Equation 



HTTP Data Transfer Cut - off Ratio [%] - 



incomplete data transfers 
successfully started data transfers 



-xlOO% 



6.8.8.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


Successfully started data transfer 


Start: Web page download starts. 


Start Method A: Reception of the first data 
packet containing content. 

Start Method B: Sending of the first GET 
command. 


Complete data transfer 


Stop: Web page download 
successfully completed. 


Stop: Reception of the last data packet 
containing content. 


Incomplete data transfer 


Stop trigger point not reached. 



Remark: 



The mobile station is already attached (see clause 5.3), a PDP context is activated (see clause 5.5) and a 
service was accessed successfully (see Service Non-Accessibility). 



6.9 



Web Radio 



6.9.1 General 

Web Radio is a term used for different types of audio streaming. Most popular, according to current perception, is the 
proprietary but de-facto-standard SHOUTCAST type which is used by WinAmp and AOL. There is an open source 
variant (ICECAST). The following descriptions refer to Shoutcast, if not mentioned otherwise. 

A typical Web radio basic scenario starts with starting up the respective client's Web Radio functionality. 

First step is retrieval of an Electronic Program Guide (EPG), typically in the form of a station list naming station name, 
genre of content offered by this station, and stream rate (which gives user's a hint on expected audio quality). This EPG 
is typically retrieved from a fixed-URL server, e.g. www.shoutcast.com . (Remark: For other clients and types of Web 
Radio, clients such as Windows Media Player or iTunes accessing respective portals are used). 

Next step is selection of a station from the list. This triggers an attempt to open the respective stream and start to receive 
content. Typically, before audio reproduction starts, the client will do some seconds of buffering. 

6.9.2 Preconditions 

With reference to the technical description above, the following KPI belong to the basic scenario only which is 
characterized as follows: 

• EPG retrieval is not part of the scenario (because in typical listening situations this is done once for multiple- 
station access). It is assumed that the station ID is already known. 

• EPG retrieval can be seen, however, as a kind of scenario extension. 

6.9.3 Special remarks on Internet radio audio playback and buffering 

Characteristic for Internet Radio audio playback is the fact that with a typical client application, no quality impairment 
other than gaps in reproduction occur. In other words, there is no poor MOS value or other continuous quality indicator, 
but simply "silence" for a period of time which cannot be estimated by the user. This fact is important when it comes to 
the definition of a useful KPI for audio quality. 
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Since the service is TCP-based and uses buffering, playback will continue until the buffer is empty. The buffer has a 
fixed maximum size, equalling a constant maximum playback time. If the buffer is full, the whole mechanism can be 
modelled by a simple differential model where new data flows in with a network-dependent data rate and flows out with 
a constant rate (playback stream rate). 

In the stationary case with buffer completely filled, incoming throughput is equal to playback stream rate, independent 
of the maximum throughput the network can deliver. If the buffer is less than full due to a previous drop in incoming 
data rate, incoming data rate will be higher (at the maximum throughput the network/IP level chain can deliver at this 
time) until the buffer is full again. 

6.9.4 Transaction Definition from Customer's perspective 

A Web Radio transaction consists of a single tune-in to a selected station, followed by music playback for a given time. 

• It is assumed that all servers being accessed (tune-in information server, stream server) are basically accessible 
and have sufficient downstream bandwidth. 

• It is assumed that the length of the tune-in list is not relevant for KPI precision under given conditions (time 
effects caused by different lengths of tune-in list to be negligible. 

6.9.5 Result Definition 

With respect to the technical description, a full Web Radio transaction has one of the following results. 



Result 


Definition 


Successful 


At least one packet of content was successfully received, and no time-out condition occurred 
up to the end of the scheduled playback time 


Dropped 


The conditions for successful transaction was not met. Examples: Unsuccessful access to the 
tune-in or stream server, loss of internet connection during playback, or a gap in playback 
longer than a pre-defined time-out value. 



It shall be noted that according to this definition, a Web Radio transaction where effectively no useable audio playback 
was possible is still considered to be technically successful. It is assumed that the fact that the transaction was useless 
and probably most annoying to the customer is reflected in another QoS describing subjective quality. Therefore, the 
situation is qualitatively equivalent to a technically stable speech telephony call with extremely poor audio MOS score. 

There is no "Failed" result because it is assumed that all phases of the transaction are part of service usage, and the 
impact of unsuccessful phases is equally negative in the user's perception. Failure therefore is always attributed to 
earlier phase such as establishment of basic internet access, or DNS access. This is, however, subject to discussion with 
respect to the A/B method distinction. 

6.9.6 KPI Overview 

The following graph shows phases in web radio usage and the coverage by KPI defined. 



Phase (user perspective) 


Retrieve EPG 


Select station 


Listen to selected station 


Phase (KPI coverage) 


EPG Retrieval 


Tune-in 


Reproduction 
set-up 








Reproduction 



Please note that for the sake of "user perspective" Reproduction set-up and Reproduction are NOT seamlessly 
connected. Reproduction set-up KPI are provided for diagnostic purposes. 

6.9.7 Web Radio EPG Retrieval Failure Ratio [%] 
6.9.7.1 Abstract Definition 

This parameter denotes the probability that a subscriber cannot access the Web Radio EPG successfully. 
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6.9.7.2 Abstract Equation 



Web Radio EPG Retrieval Failure Ratio [%] = 



unsuccessful attempts to access the EPG 
all attempts to access the EPG 



xlOO% 



6.9.7.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


EPG retrieval attempt 


Start: Customer accesses Web 
Radio EPG. 


Start: HTTP GET on EPG URL. 


Successful attempt 


Stop: EPG content successfully 
received. 


Stop: Successful reception of EPG content 
(HTTP 200 OK, eventually followed by 
additional blocks). 


Unsuccessful attempt 


Stop trigger point not reached. 



6.9.8 Web Radio EPG Retrieval Time [s] 
6.9.8.1 Abstract Definition 

This parameter describes the time period needed to access the Web Radio EPG successfully. 



6.9.8.2 Abstract Equation 



Web Radio EPG Retrieval Time [s] = (t^j^p g^ - i^i^^ er)[s] 



6.9.8.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


^start ER ■ "'"''^^ °f ^^^ retrieval 
attempt 


Start: Customer accesses Web 
Radio EPG. 


Start: Time of sending the HTTP GET on EPG 
URL. 


tg,gp ER : Time of successful 
EPG retrieval attempt 


Stop: EPG content successfully 
received. 


Stop: Time of successful reception of EPG 
content (HTTP 200 OK, eventually followed by 
additional blocks). 



6.9.9 Web Radio Tune-in Failure Ratio [%] 
6.9.9.1 Abstract Definition 

This parameter denotes the probability that a subscriber cannot obtain the tune-in information for a Web Radio 
streaming server successfully. 



6.9.9.2 Abstract Equation 



Web Radio Tune - in Failure Ratio [%] = 



unsuccessful tune - in attempts 
all tune - in attempts 



xlOO% 
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6.9.9.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


Tune-in attempt 


Start: Attempt to retrieve tune-in 
information. 


Start: Obtain tune-in information via a HTTP 
GET to a location obtained from EPG. 


Successful attempt 


Stop: Receive tune-in information. 


Stop: Successful reception of tune-in 
information (H 1 1 H 200 OK, eventually followed 
by additional blocks). 


Unsuccessful attempt 


Stop trigger point not reached. 



6.9.1 Web Radio Tune-in Time [s] 
6.9.10.1 Abstract Definition 

This parameter describes the time period needed to obtain the tune-in information for a Web Radio streaming server 
successfully. 



6.9.10.2 Abstract Equation 



Web Radio Tune - in Time [s] = (t 



Stop_TI ^StarLTI 



t)[s] 



6.9.10.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


tstart Ti ■ Tinne of tune-in attempt 


Start: Attempt to retrieve tune-in 
information. 


Start: Time when HTTP GET is issued to a 
location obtained from EPG. 


tg,gp ji : Time of successful tune- 
in attempt 


Stop: Receive tune-in information. 


Stop: Time of successful reception of tune-in 
information (HTTP 200 OK, eventually followed 
by additional blocks). 



6.9.1 1 Web Radio Reproduction Set-up Failure Ratio [%] 
6.9.1 1 .1 Abstract Definition 

This parameter denotes the probability that a subscriber cannot successfully start listening to a given Web Radio station. 



6.9.1 1 .2 Abstract Equation 



Web Radio Reproduction Set - up Failure Ratio [%] 
unsuccessful reproduction set - up attempts 
all reproduction set - up attempts 



xlOO% 
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6.9.11.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


Reproduction Set-up attempt 


Start: Attempt to retrieve audio 
stream. 


Start: Attempt to retrieve audio content from 
stream server listed in tune-in information 
(HTTP GET). 


Successful reproduction set-up 
attempt 


Stop: Indication that player starts 
buffering (may not be visible in all 
players). 


Stop: Reception of first block of content (audio 
data). 


Unsuccessful attempt 


Stop trigger point not reached. 



6.9.1 2 Web Radio Reproduction Set-Up Time [s] 
6.9.12.1 Abstract Definition 

This parameter describes the time period from request of audio stream from Stream Server to reception of first data 
packet of audio content. 

Remark: 

• Actual start of reproduction from user's point of view will be this time plus the buffer-fill time which may be 
specific to a web radio client application. 



6.9.12.2 Abstract Equation 



Web Radio Reproduction Set - up Time [s] = (t 



Stop_RP ^Start.RP 



.)[S] 



6.9.12.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


tstart_RP : Time of stream 
reproduction attempt 


Start: Indication that the audio 
stream is requested from server. 


Start: Time when HTTP GET is issued to 
Stream Server. 


tg,gp pjp :Time of reception of first 
data packet of audio content 


Stop: Indication that buffering of 
content begins. 


Stop: Receive first encoded audio data (client 
application is buffering). 



Remark: 

• Indicators listed under "customer's point of view" ,may not be shown by actual Web Radio client applications. 

6.9.13 Web Radio Reproduction Cut-off Ratio [%] 
6.9.13.1 Abstract Definition 

This parameter denotes the probability that a subscriber cannot successfully complete stream reproduction from a given 
Web Radio station for a given period of time. 

Remark: 

• Typically, web radio client applications use buffering; therefore actual audible reproduction will start a certain 
time after reception of first data packet. This parameter covers the whole reproduction time, starting from 
reception of the first data packet to avoid making assumptions for buffer length. 
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6.9.13.2 Abstract Equation 



Web Radio Reproduction Cut - off Ratio [%] : 



unsuccessful listening attempts 
all listening attempts 



xlOO% 



6.9.13.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


Listening attempt 


Start: Attempt to retrieve audio 
stream. 


Start: Attempt to retrieve audio content from 
stream server listed in tune-in information 
(HTTP GET). 


Successful listening attempt 


Stop: Reach the end of intended 
stream playback time without break 
in IP connection. 


Stop: Reach the end of intended stream 
playback time without break in IP connection. 


Unsuccessful attempt 


Stop trigger point not reached. 



6.9.1 4 Web Radio Audio Quality 



Due to the nature of Web radio which is using TCP connections, expected degradation effects are audio "gaps" (silence) 
only, resulting in buffer-empty condition resulting from insufficient bandwidth. 

At this point in time, no commonly accepted definition of perceived audio quality under these conditions exists. 
Definition of such a MOS value would be outside of the scope of the STQ MOBILE group anyway. It is clear that for 
such a perceptual measure, all aspects of possible audio gaps need to be taken into account, namely: 

• gap duration; 

• frequency of gaps; 

• time between gaps. 

For the time being, it is recommended to report the basic data on gaps on an event basis only. 

In any case, codec and stream rate (encoded bit rate) needs to be part of measurement definition since it will have 
decisive impact on results. 
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6.10 WLAN service provisioning with HTTP based authentication 
6.10.1 Generic Signal Flow 

KPI legend: 



User API scan 
attempt 

API list display 



UE 



MLME-SCAN. request sent 
MLME-SCAN. confirm received 



User WLAN 
connection attempt 

WLAN connection 
^ established 



WLAN Provider 
Access Point 



MLME-JOIN.request sent 
MLME-JOIN.confirm received 



"Connected to network" 



Target page request 



^ Landiti^ p_a^e loaded 

Send payment data and 
session settings 



"Login Success" 



Targetpage request 

(In case of no redirection) 



Target page loaded 
_ Ses_sio^lo£out _ 



"Logout success" 
User WLAN disconnection 



Authentication request 



Authentication confirm 



MLME-ASSOCIATE.request 



, MLME-ASSOCIATE.confirm 



DHCP.DISCOVER 



DHCP.ACK 



HTTP GET 



302 Moved temporarily 



HTTP GET Landing page 



Provider Landing Page 



I 



HTTP POST Pavment data 



Login success indication 



HTTP GET 



Target page 



I 



HTTP POST Logout 



Provider Logout page 



MLME-DISCONNECTED 



WLAN Provider 
Proxy 



Internet Service 
Provider 



Figure 26: Generic Signal Flow 
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6.1 0.2 WLAN Scan Failure Ratio [%] 
6.10.2.1 Abstract Definition 

The WLAN scan failure ratio denotes the probability that no desired active APs could be found in an area where 
WLAN should be present. 



6.10.2.2 Abstract Equation 



WLAN Scan Failure Ratio [%h ""^"^^^^^^'1 ^^^" ^"empts ^^^^ ^^ 

total attempts to scan WLAN APs 



WLAN UE 



WLAN Station 
Management Unit 


lUILIUIE-SCAN.request 


WLAN Station 
Scan Unit 














lUILIUIE-SC AN. confirm 

















Figure 27: SCAN Signal Flow 



6.10.2.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


Scan attempt 


start: Customer attempts to scan 
for available APs 


Start: First "IVILME-SGAN. request" containing 
the target SSID sent 


Successful scan attempt 


Stop: List of available APs is 
displayed including desired SSID 


Stop: "IVILME-SCAN. confirm containing the 
target SSID received 


Unsuccessful scan attempt 


Stop trigger not reached 



Preconditions for measurement: 

• It is possible that a scan to all access points in the area (Broadcast) is answered by an access point other than 
the desired one. To make sure that only the correct access point answers, the scan request shall contain the 
desired SSID. 

• Usually, operating systems keep a list of preferred access points and sporadically scan for these access points 
automatically. These automated scans shall be deactivated and the list shall be kept empty. 

For farther study: It should be analysed if the time to scan can vary depending on the applied scan method, i.e. if an 
aimed scan with the target operator"s SSID leads to faster/slower confirmation than a broadcast scan to all access points 
in the area. 

6.1 0.3 WLAN Time to Scan [s] 
6.10.3.1 Abstract Definition 

WLAN time to scan denotes the time it takes to scan for available access points. 
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6.10.3.2 Abstract Equation 



WLAN Time to Scan [s] = (t 



Scan result received Scan started 



^ Scan started/ P 



WLAN UE 



WLAN Station 
Management Ur|it 



WLAN Statior 
Scan Unit 



MLME-SCAN.request 




Figure 28: SCAN Signal Flow 



6.10.3.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


^Scan started : Time of scan attempt 


Start; Customer attempts to scan 
for available APs. 


Start: First "MLME-SCAN.request" containing 
the target SSID sent. 


*Scan result received ■ Time of 
successful scan attempt 


Stop: List of available APs is 
displayed, including target SSID. 


Stop: "MLME-SCAN. confirm" containing the 
target SSID received. 



Preconditions for measurement: 

• It is possible that a scan to all access points in the area (Broadcast) is answered by another access point than 
the desired one. To make sure that only the correct access point answers, the scan request shall contain the 
desired SSID. 

• Usually, operating systems keep a list of preferred access points and sporadically scan for these access points 
automatically. These automated scans shall be deactivated and the list shall be kept empty. 

NOTE: The authorization time that is consumed for entering and receiving the password has an effect on the time 
to scan. 

For further study: It should be analysed if the time to scan can vary depending on the applied scan method, i.e. if an 
aimed scan with the target operator's SSID leads to faster/slower confirmation than a broadcast scan to all access points 
in the area. 

6.1 0.4 WLAN PS Data Service Provisioning Failure Ratio [%] 
6.10.4.1 Abstract Definition 

The WLAN PS data service provisioning failure ratio denotes the probability that a customer cannot get in position to 

access services in a WLAN area. 



6.10.4.2 Abstract Equation 



WLAN PS Data Service Provisioning Failure Ratio [%\ - 



unsuccessful connect attempts 
all connect attempts 



xIOO% 
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WLAN UE 



1 




WLAN Station 
Management Unit 




WLAN Station 
Scan Unit 






MLME-JOIN.request , 






^ MLME-JOIN.confirm 









Figure 29: JOIN Signal Flow 

WLAN UE Access 

Point 
Internal MLME-JOIN.req sent 
Internal MLME-JOIN.conf received 



Authentication.req. 



Authentication.conf. 



Associate.req 



Associate.conf 



■ Login success indication 



Provider Web 
Server 



Figure 30: WLAN PS Data Service Provisioning Signal Flow 



6.10.4.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


Connect attempt 


Start: Customer attempts to 
connect to the wireless network. 


Start: First "MLME-JOIN.request" sent. 


Successful connect attempt 


Stop: Authorization confirmed by 
receiving login success indication. 


Stop: Reception of the first data packet of a 
page indicating login success. 


Unsuccessful connect attempt 


Stop trigger not reached. 



NOTE 1 : After authorization, some operators will automatically redirect the user to the URL that was entered in the 
initial portal access attempt which led to the landing page redirection. Other operators display a login 
success page of sorts and do not redirect users to their initially entered URL. 

NOTE 2: The implicit authorization failure ratio also depends on the authorization method, e.g. voucher received 
by SMS versus credit card. Thus, measurements based on different authorization method can not be 
compared. 
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6.1 0.5 WLAN PS Data Service Provisioning Time [s] 
6.10.5.1 Abstract Definition 

The WLAN PS data service provisioning time denotes the time it takes until the user is authorized in WLAN and in 
position to access services. 



6.10.5.2 Abstract Equation 



WLAN PS Data Service Provisioning Time [s] = (t 



Target URLreceived Connect option selected 



)[s] 



WLAN UE 



WLAN Station 
\/lanagement Unit 



WLAN Statiori 
Scan Unit 



MLME -JOIN.request 



MLME- JOIN.confirm 



Figure 31 : JOIN Signal Flow 



WLAN UE 



Internal MLME-JOIN.req sent 
Internal MLME-JOIN.conf received 



Access 
Point 



Authentication.req. 



Authentication.conf. 



Associate.req 



Associate.conf 



^.Loqin success indication 



WLAN Provider 
Proxy 



Figure 32: WLAN PS Data Service Provisioning Signal Flow 
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6.10.5.3 Trigger Points 



Event from abstract 
equation 


Trigger point from 
customer's point of view 


Teclinical description / protocol part 


^Connect option selected ■ Time 
of connect attempt 


Start: Customer attempts to 
connect to wireless network. 


Start: First 'MLME-JOIN. request" sent. 


Wget URL received ■ ^ime of 
successful connect attempt 


Stop: Authorization confirmed 
by receiving login success 
indication. 


Stop: Reception of the first data packet 
of a page indicating login success. 



NOTE 1 : After authorization, some operators will automatically redirect the user to the URL that was entered in the 
initial portal access attempt which led to the landing page redirection. Other operators display a login 
success page of sorts and do not redirect users to their initially entered URL. 

NOTE 2: The implicit authorization time also depends on the authorization method, e.g. voucher received by SMS 
versus credit card. Thus, measurements based on different authorization method can not be compared. 

NOTE 3: The implicit authorization time that is consumed for entering and receiving the password has an effect on 
the PS data service provisioning time. 

6.1 0.6 WLAN Association Failure Ratio [%] 
6.10.6.1 Abstract Definition 

The WLAN association failure ratio denotes the probability that a user cannot establish a radio link with the chosen 
access point. 



6.10.6.2 Abstract Equation 



,^„ .^^. . . ^ ., „ . r^i unsuccessful association attempts ,„„^ 

WLANAssociation Failure Ratio [%J = i— xlOO % 

all association attempts 



WLAN UE 



Access Point 



Internal MLME-JOIN.request sent 
Internal MLME-JOIN.confirm received 








Auj 


hentication.req 




Authentication.conf 






Associate.req 




Associate.conf 













Figure 33: WLAN ASSOCIATION Signal Flow 



6.10.6.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


Association attempt 


Start: Customer attempts to 
connect to wireless network. 


Start: First "MLME-JOIN.request" sent. 


Successful association attempt 


Stop: Connection to access point 
established and displayed. 


Stop: "MLME-ASSOCIATE. confirm" received 
with status code "success". 


Unsuccessful association attempt 


Stop trigger not reached. 
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6.1 0.7 WLAN Association Time [s] 

6.10.7.1 Abstract Definition 

The WLAN association time denotes the time it takes to associate with the chosen access point. 

6.10.7.2 Abstract Equation 



WLAN Association Time [s]= (t 



Successfulassociaticn Associaticn start 



.)[s] 



WLAN UE 



Access Point 



Internal MLME-JOIN.request sent 
Internal MLME-JOIN.confirm received 








Authentication. req 




Authentication.conf 






Associate.req 




Associate.conf 













Figure 34: WLAN ASSOCIATION Signal Flow 



6.10.7.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


Association start: Time of 
association attempt 


Start: Customer attempts to 
connect to wireless network 


start: First "MLME-JOIN.request" sent 


^Successful association '■ Time of 
successful association attempt 


stop: Connection to access point 
established and displayed 


Stop: "MLME-ASSOCIATE. confirm" received 
with status code "success" 



NOTE: The authorization time that is consumed for entering and receiving the password has an effect on the 
association time. 

6.1 0.8 WLAN IP Address Allocation Failure Ratio [%] 
6.10.8.1 Abstract Definition 

The WLAN IP address allocation failure ratio denotes the probability that a user is not allocated an IP address by the 
access point. 



6.10.8.2 Abstract Equation 



WLAN IP Address Allocation Failure Ratio % 



unsuccessful attempts to allocate IP address 
all IP address allocation requests 



xlOO % 
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6.10.8.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


IP address allocation request 


Start: Attempt to acquire network 
address and display of status. 


Start: First "DHCP.DISCOVER" sent. 


Successful attempt to allocate IP 
address 


Stop: Connection to network 
established and displayed. 


Stop: "DHCP.ACK" received with valid IP 
address. 


Unsuccessful attempt to allocate 
IP address 


Stop trigger not reached. 



6.1 0.9 WLAN IP Address Allocation Time [s] 
6.10.9.1 Abstract Definition 

The WLAN IP address allocation time denotes the time it takes the access point to allocate an IP address to the user's 
system. 



6.10.9.2 Abstract Equation 



WLAN IP Address Allocation Time [s]= (t 



IP reception IP allocation start 



)[s] 



6.10.9.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


V allocation start : Time of IP 
address allocation request 


Start: Attempt to acquire network 
address and display of status. 


Start: First "DHCP.DISCOVER" sent. 


V reception ■ Time of successful 
attempt to allocate IP address 


Stop: Connection to network 
established and displayed. 


Stop: "DCHP.ACK" received with valid IP 
address. 



NOTE: The authorization time that is consumed for entering and receiving the password has an effect on the IP 
address allocation time. 

6.10.10 WLAN Landing Page Download Failure Ratio [%] 
6.10.10.1 Abstract Definition 

The WLAN landing page download failure ratio denotes the probability that the landing page to which a user will be 
redirected for login to the WLAN cannot be successfully downloaded after requesting the target page. 



6.10.10.2 Abstract Equation 



WLAN Landing Page Download Failure Ratio [%\ 



unsuccessful landing page download attempts 
all landing page download attempts 



xlOO% 
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6.10.10.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


Landing page download attempt 


Start: Customer enters target URL 
and requests the desired page. 


Start: "HTTP_GET" for the target page sent. 


Successful landing page 
download attempt 


Stop: Landing page download 
finished. 


Stop: Last HTTP data packet of the landing 
page received. 


Unsuccessful landing page 
download attempt 


Stop trigger not reached. 



Preconditions for measurement: 

• The measurement system shall be disconnected from the WLAN prior to each measurement cycle. 

• The cache shall be emptied prior to each measurement cycle and keep alive shall be deactivated / suppressed. 

6.1 0. 11 WLAN Landing Page Download Time [s] 
6.1 0.1 1 .1 Abstract Definition 

The WLAN landing page download time denotes the time it takes for redirection and download of the landing page 
provided to login to the WLAN successfully, after the user has tried to access some webpage. 



6.1 0.1 1 .2 Abstract Equation 



WLAN Landing Page Download Time [s] = (t 



Landing page successfully downloaded Webpage resquest 



;st sent-' Pj 



6.10.11.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


Wbpage request sent : Time of 
landing page download attempt 


Start: Customer enters target URL 
and requests the desired page. 


Start: "HTTP_GET" for the target page sent. 


^Landing page successfully downloaded ■ 
Time of successful landing page 
download attempt 


Stop: Landing page download 
finished. 


Stop: Last HTTP data packet of the landing 
page received. 



Preconditions for measurement: 

• The measurement system shall be disconnected from the WLAN prior to each measurement cycle. 

• The cache shall be emptied prior to each measurement cycle and keep alive shall be deactivated / suppressed. 

NOTE: The authorization time that is consumed for entering and receiving the password has an effect on the 
landing page download time. 

6.10.12 WLAN Landing Page Password Retrieval Failure Ratio [%] 
6.10.12.1 Abstract Definition 

The WLAN landing page password retrieval failure ratio denotes the probability that the password to get submitted via 
the landing page is not received by the customer. 
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6.10.12.2 Abstract Equation 



WLAN Landing Page Password Retrieval Failure Ratio [%J 



unsuccessiul password retrieval attempts 
all password retrieval attempts 



xlOO% 



6.10.12.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


Password retrieval attempt 


Start: Authorization form filled in 
and submitted. 


Start: "TCP SYN." 


Successful password retrieval 
attempt 


Stop: Depending on used service, 
e.g. SMS with password received 
successfully. 


Stop: Depending on used service, e.g. SMS 
with password received successfully. 


Unsuccessful password retrieval 
attempt 


Stop trigger not reached. 



NOTE: The password retrieval failure ratio can be neglected when the credit card payment method is used. 

6.10.13 WLAN Landing Page Password Retrieval Time [s] 
6.10.13.1 Abstract Definition 

The WLAN landing page password retrieval time denotes the time it takes to request and receive a password to get 
submitted via the landing page. 



6.10.13.2 Abstract Equation 



WLAN Landing Page Password Retrieval Time [s] = (t 



Password received Authorisation request subinitted 



)[s] 



6.10.13.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


^Authorisation request submitted ■ ' "^^ 

of password retrieval attempt 


Start: Authorization form filled in 
and submitted. 


Start: "TCP SYN". 


^Password received ■ Time of 
successful password retrieval 
attempt 


Stop: Depending on used service, 
e.g. SMS with password received 
successfully. 


Stop: Depending on used service, e.g. SMS 
with password received successfully. 



NOTE 1 : The password retrieval time can be neglected when the credit card payment method is used. 

NOTE 2: The authorization time that is consumed for entering and receiving the password has an effect on the 
landing page password retrieval time. 

6.10.14 WLAN Landing Page Authorization Failure Ratio [%] 
6.10.14.1 Abstract Definition 

The WLAN landing page authorization failure ratio denotes the probability that the customer authorization process via 
the landing page is not successful. 



6.10.14.2 Abstract Equation 



WLAN Landing Page Authorisation Failure Ratio [%\ - 



unsuccessful authorisation attempts 
all authorisation attempts 



xlOO% 
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6.10.14.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


Authorization attempt 


Start: Password or payment data is 
submitted. 


Start: "HTTP POST" sent. 


Successful authorization attempt 


Stop: Authorization confirmed by 
receiving login success indication. 


Stop: Reception of the first data packet of a 
page indicating login success. 


Unsuccessful authorization 
attempt 


Stop Trigger not reached. 



NOTE 1 : After authorization, some operators will automatically redirect the user to the URL that was entered in the 
initial portal access attempt which led to the landing page redirection. Other operators will display a login 
success page of sorts and not redirect the user to the initially entered URL. 

NOTE 2: The authorization failure ratio also depends on the authorization method, e.g. voucher received by SMS 
versus credit card. Thus, measurements based on different authorization method can not be compared. 

6.1 0.1 5 WLAN Landing Page Authorization Time [s] 
6.10.15.1 Abstract Definition 

The WLAN landing page authorization time denotes the time it takes to perform user authorization via the landing page. 



6.10.15.2 Abstract Equation 



WLAN Landing Page Authorisation Time [s] = {t 



Authorisation confirmed Password is submitted 



)[s] 



6.10.15.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


^Password is submitted ■ "'"''^® °f 
authorization attempt 


Start: Password or payment data is 
submitted. 


Start: "HTTP POST" sent. 


Authorisation confirmed ■ Time Of 

successful authorization attempt 


Stop: Authorization confirmed by 
receiving login success indication. 


Stop: Reception of the first data packet of a 
page indicating login success. 



NOTE 1 : After authorization, some operators will automatically redirect the user to the URL that was entered in the 
initial portal access attempt which led to the landing page redirection. Other operators display a login 
success page of sorts and do not redirect users to their initially entered URL. 

NOTE 2: The authorization time also depends on the authorization method, e.g. voucher received by SMS versus 
credit card. Thus, measurements based on different authorization method can not be compared. 

NOTE 3: The authorization time that is consumed for entering and receiving the password has an effect on the 
landing page authorization time. 

6.10.16 WLAN Re-accessibility Failure Ratio [%] 
6.10.16.1 Abstract Definition 

The WLAN re-accessibility failure ratio denotes the probability that re-accessing the access point is not successful 
because of a WLAN failure. 
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6.10.16.2 Abstract Equation 



T^TT «,.TT^ •, •,• ^ ; T^ • r^i unsuccessM attempts reaccess ,„^^ 

WLAN Re - accessibility Failure Ratio [%\ = x 1 00 % 

all attempts to reaccess 



WLAN UE 



Access Point 



Associate.req 



Associate.conf 



Figure 35: WLAN RE- ASSOCIATION Signal Flow 



6.10.16.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


Attempt to reaccess 


Start: Access point is displayed in 
the list of available access points. 


Start: First "IVILME-ASSOCIATE. request" sent 
after radio signal is sufficient again. 


Successful attempt to reaccess 


Stop: IVIessage that the WLAN 
adapter is ready (IVIAC address of 
AP is available). 


Stop: "MLME-ASSOCIATE. confirm" has been 
received with status code "success". 


Unsuccessful attempt to 
reaccess 


Stop trigger point not reached. 



6.10.17 WLAN Re-accessibility Time [s] 

6.10.17.1 Abstract Definition 

The WLAN re-accessibility time denotes the time it takes to re-establish a lost radio link with the access point after the 
signal is sufficient again. 

6.10.17.2 Abstract Equation 



WLAN Re - accessibility Time [s] = (t 



AP'sMACaddressis available AP reappearsin list 



.)[s] 



WLAN UE 



Access Point 



Associate.req 



Associate.conf 



Figure 36: WLAN RE-ASSOCIATION Signal Flow 
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6.10.17.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


Up reappears in list ■ Time of attempt 
to reaccess 


Start: access point is displayed in 
the list of available access points. 


Start: First "IVILME-ASSOCIATE.request" sent 
after radio signal is sufficient again. 


Up"s mac address is available ■ Time 
of successful attempt to reaccess 


Stop: message that the WLAN 
adapter is ready. 


Stop: "MLME-ASSOCIATE. confirm" has been 
received with status code "success". 



NOTE: The authorization time that is consumed for entering and receiving the password has an effect on the 
re-accessibility time. 

6.10.18 WLAN Logout Page Download Failure Ratio [%] 

6.10.18.1 Abstract Definition 

The WLAN logout page download failure ratio denotes the probability that the logout process is not successful. 

6.10.18.2 Abstract Equation 



WLAN Logout Page Download Failure Ratio [%J 



unsuccessful logout page download attempts 
all logout page download attempts 



xlOO% 



6.10.18.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


Logout page download attempt 


Start: Decision to logout is 
submitted 


Start: "HTTP POST" sent 


Successful logout page 
download attempt 


Stop: Logout confirmed by 
receiving logout page 


Stop: Reception of first data packet of logout 
page 


Unsuccessful logout page 
download attempt 


Stop Trigger not reached 



6.10.19 WLAN Logout Page Download Time [s] 

6.10.19.1 Abstract Definition 

The WLAN logout page download time denotes the time it takes to perform user logout. 

6.10.19.2 Abstract Equation 



WLAN Logout Page Download Time [s] = (t 



Logout confirmed Logout procedure start 



)[s] 



6.10.19.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


^Logout procedure start ■ Time of 
logout page download attempt 


Start: Decision to logout is 
submitted. 


Start: "HTTP POST" sent. 


^Logout confirmed ■ Time of 
successful logout page download 
attempt 


Stop: Logout confirmed by 
receiving logout page. 


Stop: Reception of first data packet of logout 
page. 
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NOTE: The authorization time that is consumed for entering and receiving the password has an effect on the 
logout page download time. 

6.1 1 Wireless Application Protocol (WAP) 

WAP (Wireless Application Protocol) is a specification for a set of communication protocols to standardize the way that 
wireless devices, such as cellular telephones and radio transceivers, can be used for Internet access, including e-mail, 
the World Wide Web, newsgroups, and instant messaging. Devices and service systems that use WAP are able to 
interoperate. 

The WAP layers are: 

• Wireless Application Environment (WAE); 

• Wireless Session Layer (WSL); 

• Wireless Transport Layer Security (WTLS); 

• Wireless Transport Layer (WTP). 

WAP is a technology designed to allow efficient transmission of optimized Internet content to cell phones. 
The parameters of clause 6.11 are represented in figure 37. 
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Figure 37: Parameter and service overview 
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The Technical description/protocol part of the Parameters of the whole clause are represented in the following "WAP 
Message Sequence Chart". 



UE 

1 

4 

5 

8 

9 

11 

14 

16 



o PDP Context Activation Request >» 

<« PDP Context Activation ACCEPT o 

o WSP Connect or TCP SYN >» 

<« WSP Connect Reply or TCP SYN ACK o 

o WTP ACK or TCP ACK >» 

o WSP or HTTP Get Request >» 

<« First Data Packet containing content o 

<« Last Data Packet containing content o 



WWP 

2 

3 

6 

7 

10 

12 

13 

15 



Figure 38: WAP Message Sequence Chart 

NOTE: WSP Connection usually occurs once per session, TCP connection is more frequent. 

6.11 .1 WAP Activation Failure Ratio [%] (WAP 1 .x only) 

6.11 .1 .1 Abstract Definition 

The parameter WAP Activation Failure Ratio describes the probability that the WAP session could not be activated in 
case of WAP 1.x connection-mode session service. 

6.11.1.2 Abstract Equation 



WAP Activation Failure Ratio [%] 



unsuccessful WAP activation attempts 
all WAP activation attempts 



xlOO% 



6.11.1.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description / 
protocol part 


WAP activation attempt 


Not applicable. 


start: WSP Connect procedure. 


Successful WAP activation attempt 


Not applicable. 


Stop: Reception of the WSP Connect 
Reply. 


Unsuccessful WAP activation attempt 


Stop trigger point not reached. 



Remark: 

• The bearer has to be active in the cell used by a subscriber (see clause 5.1) and the mobile station has to be 
attached (see clause 5.3). 

6.1 1 .2 WAP Activation Time [s] (WAP 1 .x only) 
6.1 1 .2.1 Abstract Definition 

The parameter WAP Activation Time describes the time it takes to activate the WAP session in case of WAP 1 .x 
connection-mode session service. 
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6.11.2.2 Abstract Equation 



WAP Activation Time [s] = ( t 



WAP session established WAP session activation request 



)[s] 



6.11.2.3 Trigger Points 



Event from abstract equation 


Trigger point from 
customer's point of view 


Tecfinical description / protocol part 


Wp session activation request ■ ''"''^^ °^ 
WAP session activation request. 


Not applicable. 


Start: WSP Connect procedure 


Wp session established ■ Time when WAP 
session established. 


Not applicable. 


Stop: Reception of the WSP Connect 
Reply 



Remark: 

• The bearer has to be active in the cell used by a subscriber (see clause 5.1) and the mobile station has to be 
attached (see clause 5.3). Only successful measurements are taken into account to calculate the average time. 

6.1 1 .3 WAP {Page} IP Access Failure Ratio [%] (WAP 2.x only) 
6.1 1 .3.1 Abstract Definition 

The parameter WAP {Page} IP Access Failure Ratio denotes the probability that a subscriber cannot establish a TCP/IP 
connection to the WAP server successfully. 

NOTE: This parameter can only be calculated in case of follow up page, if the TCP/IP connection is not 
persistent. 



6.1 1 .3.2 Abstract Equation 



WAP { Page } IP Access Failure Ratio [%] = 



unsuccessful WAP IP Access attempts 
all WAP IP Access attempts 



xlOO' 



6.11.3.3 Trigger Points 



Event from abstract 
equation 


Trigger point from customer's point of 
view 


Tecfinical description / 
protocol part 


WAP IP access attempt 


Start: Selecting the link of a WAP page 
or applying an entered URL 


Start: Sending of First TCP SYN 


Successful WAP IP 
access attempt 


Not applicable. 


Stop: Sending of the first HTTP GET 
command 


Unsuccessful WAP IP 
access attempt 


Stop trigger point not reached. 



Remark: 



The bearer has to be active in the cell used by a subscriber (see clause 5.1) and the mobile station has to be 
attached (see clause 5.3) as well as the respective PDP context has to be activated (see clause 5.5). 
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6.1 1 .4 WAP {Page} IP Access Setup Time [s] (WAP 2.x only) 
6.1 1 .4.1 Abstract Definition 

The WAP {Page} IP Access Time is the time period needed to establish a TCP/IP connection to the WAP server, from 
sending the initial query to a server to the point of time when the content is demanded. 

NOTE: This parameter can only be calculated in case of follow up page, if the TCP/IP connection is not 
persistent. 



6.11.4.2 Abstract Equation 



WAP {Page} IP Access Time [s] = (t 



WAP IP connection established WAP IP connection request 



.)[s] 



6.11.4.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's point 
of view 


Technical description / protocol part 


Wp IP connection request ■ "'"''^^ °^ 
WAP IP connection request. 


Start: Selecting the link of a WAP page 
or applying an entered URL. 


start: Sending of First TCP SYN. 


Wp IP connection established ■ "'"''^^ °' 
WAP IP connection establislied. 


Not applicable. 


Stop: Sending of the first HTTP GET 
command. 



Remark: 

• The bearer has to be active in the cell used by a subscriber (see clause 5.1) and the mobile station has to be 
attached (see clause 5.3) as well as the respective PDP context has to be activated (see clause 5.5). Only 
successful measurements are taken into account to calculate the average time. 

6.1 1 .5 WAP {Page} Session Failure Ratio [%] 
6.1 1 .5.1 Abstract Definition 

The parameter WAP {Page} Session Failure Ratio is the proportion of unsuccessful WAP page access attempts and 
sessions that were started successfully. 



6.11.5.2 Abstract Equation 



WAP { Page } Session Failure Ratio [%] 



unsuccessful WAP page access attempts 
all WAP page access attempts 



xlOO% 
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6.11.5.3 Trigger Points 



Event from abstract 
equation 


Trigger point from customer's point 
of view 


Technical description / protocol part 


WAP page access 
attempt 


Start: 

Selecting the link of a WAP page or 

applying an entered URL. 


Start: 

WAP1 .x: Sending of WSP Get Request 

WAP2.X: 

a) Sending of First TCP SYN (if available) or 

b) Sending of HTTP Get Request (only if first TCP 
SYN is not available). 


Successful WAP page 
access attempt 


Stop: The requested WAP page is 
completely loaded. 


Stop: 

WAP1 .X / WAP2.X: Reception of the last data 

packet containing the corresponding content. 


Unsuccessful WAP 
page access attempt 


Stop trigger point not reached. 


NOTE: In case of WAP 2.x the start trigger should be the first TCP SYN (a). If the TCP/IP connection is not 
re-established before the request of the new page (next page part), the start Trigger has to be the first 
respective HTTP Get Request (b). 



Remark: 

• The bearer has to be active in the cell used by a subscriber (see clause 5.1) and the mobile station has to be 
attached (see clause 5.3) as well as the respective PDP context has to be activated (see clause 5.5). 

6.1 1 .6 WAP {Page} Session Time [s] 
6.1 1 .6.1 Abstract Definition 

The parameter WAP {Page} Session Time provides the time in seconds between selection of a specific WAP page and 
the successful load of the page. 



6.11.6.2 Abstract Equation 



WAP { Page } Session Time [s] = ( t 



appearance WAP page selection WAP page 



)[s] 



6.11.6.3 Trigger Points 



Event from abstract 
equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


^selection WAP page ■ 
Time of selection of 
the WAP page 


Start: Selecting the link of a WAP 
page or applying an entered URL. 


Start: 

WAP1 .x: Sending of first WSP Get Request. 

WAP2.X: 

a) Sending of First TCP SYN (if available) or 

b) Sending of HTTP Get Request (only if first TCP 
SYN is not available). 


^appearance WAP page ■ 
Time of appearance 
of the WAP page 


Stop: The requested WAP page is 
completely loaded. 


Stop: 

WAP1 .X / WAP2.X: Reception of the last data packet 

containing the corresponding content. 


NOTE: In case of WAP 2.x the start trigger should be the first TCP SYN (a). If the TCP/IP connection is not 
re-established before the request of the new page (next page part), the start Trigger has to be the first 
respective H 1 1 P Get Request (b). 



Remark: 



The bearer has to be active in the cell used by a subscriber (see clause 5.1) and the mobile station has to be 
attached (see clause 5.3) as well as the respective PDP context has to be activated (see clause 5.5). Only 
successful measurements are taken into account to calculate the average time. 
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6. 11 .7 WAP {Page} Request Failure Ratio [%] 
6.1 1 .7.1 Abstract Definition 

The WAP {Page} Request Failure Ratio denotes the probability that a WAP page request is not successful after a 
timeout period. 



6.11.7.2 Abstract Equation 



WAP {Page} Request Failure Ratio [%] = 



unsuccessiul WAP page request attempts 
all WAP page request attempts 



xlOO % 



6.11.7.3 Trigger Points 



Event from abstract 
equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


WAP page request 
attempt 


Start: Selecting the link of the WAP 
page. 


Start: 

WAP1 .x: Sending of WSP Get Request 

WAP2.X: Sending of HTTP Get Request. 


Successful WAP page 
request attempt 


Stop: Download begins. 


Stop: 

WAP1 .X / WAP2.X: Reception of the first data packet 

containing content. 


Unsuccessful WAP 
page request attempt 


Stop trigger point not reached. 



Remark: 

• The bearer has to be active in the cell used by a subscriber (see clause 5.1) and the mobile station has to be 
attached (see clause 5.3) as well as the respective PDP context has to be activated (see clause 5.5). 

6.1 1 .8 WAP {Page} Request Time [s] 
6.1 1 .8.1 Abstract Definition 

The parameter WAP {Page} Request Time describes the duration between selection of a specific WAP page and the 
reception of the first data packet containing WAP page content. 



6.11.8.2 Abstract Equation 



WAP {Page} Request Time [s]= (t 



first data packet reception selection WAP page 



J[s] 



6.11.8.3 Trigger Points 



Event from abstract 
equation 


Trigger point from 
customer's point of view 


Technical description / protocol part 


Election WAP page ■ Time of 
selection of the WAP site. 


Start: Selecting the link of the 
WAP page. 


Start: 

WAP1 .x: Sending of WSP Get Request 

WAP2.X: Sending of H II P Get Request. 


nirst data packet reception ■ 
Time of first data packet 
reception. 


Stop: Download begins. 


Stop: 

WAP1 .X / WAP2.X: Reception of the first data packet 

containing content. 



Remark: 



The bearer has to be active in the cell used by a subscriber (see clause 5.1) and the mobile station has to be 
attached (see clause 5.3) as well as the respective PDP context has to be activated (see clause 5.5). Only 
successful measurements are taken into account to calculate the average time. 
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6. 11 .9 WAP {Page} Mean Data Rate [kbit/s] 
6.1 1 .9.1 Abstract Definition 

The WAP {Page} Mean Data Rate denotes the average data rate (WAP throughput) in kbit/s. 



6.11.9.2 Abstract Equation 



WAP page size [kbyte] ■ 



WAP { Page } Mean Data Rate [kbit/s] = 



8 [kbit] 
[kbyte] 



(t 



last data packet reception first data packet reception 



)[s] 



6.11.9.3 Trigger Points 

The average throughput is measured from opening the data connection to the end of the successful transfer of the 
content (file, WAP page). 



Event from abstract 
equation 


Trigger point from customer's 
point of view 


Teclinical description / protocol part 


^first data packet reception ■ 
Time of first data 
packet reception 


Start: Download begins. 


start: 

WAP1 .X / WAP2.X: Reception of the first data packet 

containing content. 


Mast data packet reception ■ 
Time of last data 
packet reception 


stop: Download is completed. 


Stop: 

WAP1 .X / WAP2.X: Reception of the last data packet 

containing the corresponding content. 



Remark: 

• The bearer has to be active in the cell used by a subscriber (see clause 5.1) and the mobile station has to be 
attached (see clause 5.3) as well as the respective PDP context has to be activated (see clause 5.5). 

6.1 1 .1 WAP {Page} Data Transfer Cut-off Ratio [%] 
6.11.10.1 Abstract Definition 

The WAP {Page} Data Transfer Cut off Ratio denotes the probability that a data download is incomplete after a timeout 
period (the download is aborted). 



6.1 1 .1 0.2 Abstract Equation 



WAP I Page } Data Transfer Cut off Ratio [%] 



incomplete WAP page transfer attempts 
all WAP page transfer attempts 



xlOO% 



6.11.10.3 Trigger Points 



Event from 
abstract equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


WAP page transfer 
attempt 


Start: Download begins. 


Start: 

WAP1 .X / WAP2.X: Reception of the first data packet 

containing content. 


Successful WAP 
page transfer 
attempt 


Stop: Download is completed. 


Stop: 

WAP1 .X / WAP2.X: Reception of the last data packet 

containing the corresponding content. 


Incomplete WAP 
page transfer 
attempt 


Stop trigger point not reached. 
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Remark: 

• The bearer has to be active in the cell used by a subscriber (see clause 5.1) and the mobile station has to be 
attached (see clause 5.3) as well as the respective PDP context has to be activated (see clause 5.5). 

6.11 .11 WAP {Page} Data Transfer Time [s] 
6.11.11.1 Abstract Definition 

The parameter WAP {Page} Data Transfer Time describes the duration between the reception of the first data packet 
and the last data packet containing WAP page content. 



6.11.11.2 Abstract Equation 



WAP { Page } Data Transfer Time [s] = (t 



last data packet reception first data packet reception 



„)[s] 



6.11.11.3 Trigger Points 



Event from abstract 
equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


^first data packet reception ■ 
Time of first data 
packet reception 


Start: Download begins. 


Start: 

WAP1 .X / WAP2.X: Reception of the first data packet 

containing content. 


Mast data packet reception ■ 
Time of last data 
packet reception 


Stop: Download is completed. 


Stop: 

WAP1 .X / WAP2.X: Reception of the last data packet 

containing the corresponding content. 



Remark: 



The bearer has to be active in the cell used by a subscriber (see clause 5.1) and the mobile station has to be 
attached (see clause 5.3) as well as the respective PDP context has to be activated (see clause 5.5). Only 
successful measurements are taken into account to calculate the average time. 



7 Store-and-forward (S&F) Services QoS Parameters 

The "Store-and-forward" concept can be used for every non realtime service called "Background Class", which uses the 
following communication concept. We have two clients and one or more servers in the middle for each service. 

• The A-party uploads a message to a server; 

• this server forwards this message to another server (this step is optional); 

• the server notifies the B-party that a new message is available; 

• the B-party downloads this message. 

The customers experience is similar in all services which follows the "Store-and-forward" approach. 

In this raster, it's possible to fill in nearly all parameters which is done in the following clauses. 

At the beginning of each service-dependent-clause, you will find this diagram (7.1.1) in an aligned version according to 
the service. The parameter names are therefore replaced. Empty parameter boxes means that the parameter is not 
already defined. 
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7.1 Generic Store-and-forward Parameters 

This clause "Generic Store-and-forward Parameters" should be used for all services which works as described in the 
introduction of clause 7 and isn't defined already within this clause separately. Especially services who use proprietary 
or encrypted communication between the user devices are dedicated to use the following generic described parameter 
concept. 

7.1.1 Parameter Overview Cinart 

All services within this clause "Store-and-forward (S&F) Services QoS Parameters" complie to the same structure as it's 
displayed in the following diagram. The blue part is the upload part of a message from the A-party to a server. The 
green part is the notification part. The B-party will be informed about a new message. At the end the message will be 
downloaded at the B-party side from a server, explained with the orange boxes. 
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Figure 39: Store and Forward Parameter Overview with Trigger Points 
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7.1 .2 {Service} Message Upload Failure Ratio [%] 



7.1.2.1 



Abstract Definition 



The parameter indicates the probabihty of message upload failures from the message device to the server. This 
transmission is successful for the parameter, if the message is marked as sent. 



7.1.2.2 Abstract Equation 



{ Service } Message Upload Failure Ratio [% J = 



unsuccessful message upload 
message upload attempt 



100% 



7.1.2.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's point of view 


Message upload attempt 


Push "Send" message button at A-party side. 


Successful message upload 


See end of message upload at A-party side. 


Unsuccessful message upload 


Stop trigger point not reached. 



7.1 .3 {Service} Message Upload Time [s] 
7.1.3.1 Abstract Definition 

The parameter indicates the time from pushing "send" message button on the message device until message is uploaded 
and marked as sent. 



7.1.3.2 Abstract Equation 



{ Service } Message Upload Time [s] = t 



successful message upload message upload attempt 



7.1.3.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's point of view 


IVIessage upload attempt 


Push "Send" message button at A-party side. 


Successful message upload 


See end of message upload at A-party side. 



Preconditions for measurement: 

• Message Upload shall be successful. 



7.1 .4 {Service} Message Upload Access Failure Ratio [%] 
7.1.4.1 Abstract Definition 

The parameter indicates the probability that the customer cannot successfully establish a data connection to the message 
server to upload messages. 



7.1.4.2 Abstract Equation 



fo • iiv/r TT 1 J A T- -1 Ti .• rn/n UHSUCCCSSful SCrvlcC aCCCSS . ^^^ 

{ Service } Message Upload Access Failure Ratio [%J = 100% 

service access attempt 
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7.1.4.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's point of view 


Service Access attempt 


Push "Send" message button at A-party side. 


Successful Service Access 


See start of message upload at A-party side. 


Unsuccessful Service Access 


Stop trigger point not reached. 



7.1 .5 {Service} Message Upload Access Time [s] 
7.1.5.1 Abstract Definition 

The parameter indicates the time from establishment attempt of a data connection to the message server to upload 
messages until the upload of the first message content. 



7.1.5.2 Abstract Equation 



{ Service} Message Upload Access Time [s] = t 



successful service access service access attempt 



7.1.5.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's point of view 


Service Access attempt 


Push "Send" message button at A-party side. 


Successful Service Access 


See start of message upload at A-party side. 



Preconditions for measurement: 

• Message Upload Access shall be successful. 

7.1 .6 {Service} Message Upload Data Transfer Cut-off Ratio [%] 
7.1.6.1 Abstract Definition 

The parameter indicates the probability that a data transfer of a message upload is incomplete or failed after the 
established access to the server. 



7.1.6.2 Abstract Equation 



.,,, TT, ,T^ r^ r ^ nn^ ■ r^n incomplcte data transfci ,^^„ 

{ Service} Message Upload Data Transfer Cut - off Ratio [%] = ^ 100% 

data transfer attempt 



7.1.6.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's point of view 


Data transfer attempt 


First data packet is sent by the A-party side. 


Complete data transfer 


See end of message upload at A-party side. 


Incomplete data transfer 


Stop trigger point not reached. 



7.1.7 



{Service} Message Upload Data Transfer Time [s] 



7.1.7.1 



Abstract Definition 



The parameter indicates the time from opening the data connection until the end of the successful transfer of message 
content. 
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7.1.7.2 Abstract Equation 



{ Service } Message Upload Data Transfer Time [s] = t 



end of transfer start of transfer 



7.1.7.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's point of view 


Data transfer attempt 


First data packet is sent by the A-party side. 


Complete data transfer 


See end of message upload at A-party side. 



Preconditions for measurement: 

• Message Upload Data Transfer shall be successful. 

7.1 .8 {Service} Notification Start Failure Ratio [%] 
7.1.8.1 Abstract Definition 

Probability that the B-party side cannot see the start of the notification transmission after successful upload of the 
message by the A-party side. 



7.1.8.2 Abstract Equation 



■ ,-.. -r- ■ „ ^ •. „ • r^n unsuccessful notification start ,„„^ 

{ Service} Notification Start Failure Ratio [%\ = 100 % 

succesful sent message 



7.1.8.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's point of view 


Successful sent message 


See end of message upload at A-party side. 


Successful start of notification download 


See start of notification download at B-party side. 


Unsuccessful start of notification download 


Stop trigger point not reached. 



7.1 .9 {Service} Notification Start Time [s] 
7.1.9.1 Abstract Definition 

The parameter indicates the time from finished upload of a message at A-party side until start of notification download 
at B-party side. 



7.1.9.2 Abstract Equation 



{Service} Notification Start Time [s] = t 



successful sent message successful start of notification download 



7.1.9.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's point of view 


Successful sent message 


See end of message upload at A-party side. 


Successful start of notification download 


See start of notification download at B-party side. 



Preconditions for measurement: 

• Notification Start shall be successful. 
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7.1.10 {Service} Notification Download Failure Ratio [%] 

7.1 .1 0.1 Abstract Definition 

The parameter indicates the probability that the end-customer can"t download the notification of a new message. 

7.1 .1 0.2 Abstract Equation 



{Service} Notification Download Failure Ratio [%] = 



unsuccessful download of notification 
notification download attempt 



■ 100 % 



7.1.10.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's point of view 


Notification download attempt 


See start of notification download at B-party side. 


Successful download of notification 


See notification is received at B-party side. 


Unsuccessful download of notification 


Stop trigger point not reached. 



7.1 .1 1 {Service} Notification Download Time [s] 

7.1 .1 1 .1 Abstract Definition 

The parameter indicates the time from start until the end of the notification download. 

7.1.11.2 Abstract Equation 



{ Service } Notification Download Time [s] = t 



successful download of notification notification download attempt 



7.1.11.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's point of view 


Notification download attempt 


See start of notification download at B-party side. 


Successful download of notification 


See notification is received at B-party side. 



Preconditions for measurement: 

• Message Notification Download shall be successful. 

7.1 .12 {Service} Notification Download Access Failure Ratio [%] 

7.1 .1 2.1 Abstract Definition 

The parameter indicates the probability that the customer cannot successfully establish a data connection to the message 
server to download the notification data of a new message. 

7.1.12.2 Abstract Equation 



{Service} Notification Download Access Failure Ratio [%\ = 



unsuccessful received first data packet 
notification download attempt 



100% 
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7.1.12.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's point of view 


Notification download attempt 


See start of notification download at B-party side. 


Successful received first data packet 


See first incoming notification data at B-party side. 


Unsuccessful received first data packet 


Stop trigger point not reached. 



7.1 .13 {Service} Notification Download Access Time [s] 
7.1 .1 3.1 Abstract Definition 

The parameter indicates the time from start of data connection to the message server to download the notification data 
of a new message until the reception of the first data of this notification. 



7.1 .1 3.2 Abstract Equation 



{ Service } Notification Download Access Time [s] = t 



successful received firstdata packet notification download attempt 



7.1.13.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's point of view 


Notification download attempt 


See start of notification download at B-party side. 


Successful received first data packet 


See first incoming notification data at B-party side. 



Preconditions for measurement: 

• Notification Download Access shall be successful. 

7.1 .14 {Service} Notification Data Transfer Cut-off Ratio [%] 
7.1 .1 4.1 Abstract Definition 

The parameter indicates the probability that a data transfer of a notification download is incomplete or failed after the 
established access to the server. 



7.1.14.2 Abstract Equation 



{Service} Notification Data Transfer Cut - off Ratio [%\ = 



incomplete notification data transfer 
notification data transfer attempt 



100% 



7.1.14.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's point of view 


Notification Data Transfer attempt 


See first incoming notification data at B-party side. 


Complete notification data transfer 


See notification is received at B-party side. 


Incomplete notification data transfer 


Stop trigger point not reached. 



7.1.15 {Service} Notification Data Transfer Time [s] 
7.1 .1 5.1 Abstract Definition 

The parameter indicates the time from start until end of complete notification data download. 
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7.1.15.2 Abstract Equation 



{ Service} Notification Data Transfer Time [s] = t 



complete notification data transfer notification data transfer attempt 



7.1.15.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's point of view 


Notification Data Transfer attempt 


See first incoming notification data at B-party side. 


Complete notification data transfer 


See notification is received at B-party side. 



Preconditions for measurement: 

• Notification Data Transfer shall be successful. 

7.1 .16 {Service} Message Download Failure Ratio [%] 
7.1 .1 6.1 Abstract Definition 

The parameter indicates the probability that the complete message download cannot be completed successfully. 



7.1.16.2 Abstract Equation 



. , , , ^ , , ^ ., X, . r^ 1 unsuccessful message download , ^^ ^ 

{Service} Message Download Failure Ratio [%J = 100 % 

message download attempt 



7.1.16.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's point of view 


IVIessage download attempt 


start message download at B-party side. 


Successful message download 


See complete message at B-party side. 


Unsuccessful message download 


Stop trigger point not reached. 



7.1 .1 7 {Service} Message Download Time [s] 
7.1 .1 7.1 Abstract Definition 

The parameter indicates the time from start until end of complete message download. 



7.1.17.2 Abstract Equation 



{ Service } Notification Data Transfer Time [s] = t 



successful message download message download attempt 



7.1.17.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's point of view 


IVIessage download attempt 


Start message download at B-party side. 


Successful message download 


See complete message at B-party side. 



Preconditions for measurement: 

• Message Download shall be successful. 
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7.1 .18 {Service} Message Download Access Failure Ratio [%] 
7.1 .1 8.1 Abstract Definition 

The parameter indicates the probabihty that the customer cannot successfully establish a data connection to the message 
server to download messages. 



7.1.18.2 Abstract Equation 



{Service} Message Download Access Failure Ratio [%] = 



unsuccessful service access 
service access attempt 



100% 



7.1.18.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's point of view 


Service Access attempt 


Start message download at B-party side. 


Successful Service Access 


See incoming message data at B-party side. 


Unsuccessful Service Access 


Stop trigger point not reached. 



7.1 .19 {Service} Message Download Access Time [s] 
7.1 .1 9.1 Abstract Definition 

The parameter indicates the time from start of data connection to the message server to download the message until the 
reception of the first data of this message. 



7.1 .1 9.2 Abstract Equation 



{ Service } Message Download Access Time [s] = t 



successful message service access service access attempt 



7.1.19.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's point of view 


Service Access attempt 


Start message download at B-party side. 


Successful Service Access 


See incoming message data at B-party side. 



Preconditions for measurement: 

• Message Download Access shall be successful. 

7.1 .20 {Service} Message Download Data Transfer Cut-off Ratio [%] 
7.1.20.1 Abstract Definition 

The parameter indicates the probability that a data transfer of the message download is incomplete or failed after the 
established access to the server. 



7.1.20.2 Abstract Equation 



{Service} Message Download Data Transfer Cut - off Ratio [%] = 100 % 

data transfer attempt 
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7.1.20.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's point of view 


Data Transfer attempt 


See incoming message data at B-party side. 


Complete data transfer 


See complete message at B-party side. 


Incomplete data transfer 


Stop trigger point not reached. 



7.1 .21 {Service} Message Download Data Transfer Time [s] 
7.1 .21 .1 Abstract Definition 

The parameter indicates the time from start of message data download until successful complete download of all 
message data. 



7.1 .21 .2 Abstract Equation 



{Service} Message Download Data Transfer Time [s] = t^^^p,^,^^^^^,^^^,^^ - 1,,,,^,^,^ 



attempt 



7.1.21.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's point of view 


Data Transfer attempt 


See incoming message data at B-party side. 


Complete data transfer 


See complete message at B-party side. 



Preconditions for measurement: 

• Message Download Data Transfer shall be successful. 



7.1 .22 {Service} Notification and Message Download Failure Ratio [%] 
7.1.22.1 Abstract Definition 

The parameter indicates the probability that the notification and message download cannot be completed successfully. 



7.1.22.2 Abstract Equation 



{Service} Notification and Message Download Failure Ratio [%\ 

_ unsuccessful notification and message download 
notification and message download attempt 



100% 



7.1.22.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's point of view 


Notification and message download attempt 


See start of notification download at B-party side 


Successful notification and message download 


See complete message at B-party side. 


Unsuccessful notification and message download 


Stop trigger point not reached. 



7.1 .23 {Service} Notification and Message Download Time [s] 
7.1.23.1 Abstract Definition 

The parameter indicates the time from start of data connection to the message server to download the notification data 
of a new message until the successful complete download of the message. 
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7.1.23.2 Abstract Equation 



{Service} Notification and Message Download Time [s] 



successful notification and message download notification and message download attempt 



7.1.23.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's point of view 


Notification and message download attempt 


See start of notification download at B-party side. 


Successful notification and message download 


See complete message at B-party side. 



Preconditions for measurement: 

• Notification and Message Download shall be successful. 

7.1 .24 {Service} End-to-End Failure Ratio [%] 
7.1.24.1 Abstract Definition 

The parameter indicates the probability that the complete service usage from start of message upload at the A-party side 
until the complete message download at the B-party side cannot be completed successfully. This transmission is 
unsuccessful, if the message upload, the notification (if possible) or the message download fails. 



7.1.24.2 Abstract Equation 



{Service} End - to - End Failure Ratio [%\ = 



unsuccessful message download 
message upload attempt 



100% 



7.1.24.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's point of view 


Message upload attempt 


Push "Send" message button at A-party side. 


Successful message download 


See complete message at B-party side. 


Unsuccessful message download 


Stop trigger point not reached. 



7.1 .25 {Service} End-to-End Time [s] 
7.1.25.1 Abstract Definition 

The parameter indicates the time from start until end of message upload at A-party side until the successful complete 
download of the message at B-party side. 



7.1.25.2 Abstract Equation 



{ Service } End - to - End Time[s] = t 



successful message download message upload attempt 



7.1.25.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's point of view 


Message upload attempt 


Push "Send" message button at A-party side. 


Successful message download 


See complete message at B-party side. 
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Preconditions for measurement: 

• End-to- End service usage shall be successful. 



7.2 



E-Mail 



7.2.1 



Parameter Overview Cinart 
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Figure 40: E-IVIail Parameter Overview with Trigger Points 



7.2.2 



E-IVIail {Download I Upload} Service Non-Accessibility [%] 



7.2.2.1 Abstract Definition 

The service non-accessibility ratio denotes the probabiUty that a subscriber cannot establish a PDP context and access 
the service successfully. 
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7.2.2.2 Abstract Equation 



E - Mail {Download I Upload} Service Non - Accessibility [%] = 

unsuccessful attempts to reach the point when content is sent or received 
all attempts to reach the point when content is sent or received 



xlOO% 



7.2.2.3 Trigger Points 

Download: 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


Service access attempt 


Start: Customer initiates the 
service access. 


Start: AID command. 


Successful attempt 


Stop: First content is received. 


Stop Method A: Reception of the first data 
packet containing content. 

Stop IVIethod B: Send RETR command. 


Unsuccessful attempt 


Stop trigger point not reached. 



Upload: 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


Service access attempt 


Start: Customer initiates the 
service access. 


Start: ATD command. 


Successful attempt 


Stop: First content is sent. 


Stop IVIethod A: Sending of the first data packet 
containing content. 

Stop IVIethod B: Reception of the positive 
acknowledgement (250) for the HELD 
command which was sent from the client 
before. This definition applies to the "none login 
procedure", for other login procedures the 
trigger point has to be defined. 


Unsuccessful attempt 


Stop trigger point not reached. 



Remark: 

• The PS bearer has to be active in the cell used by a subscriber (see clause 5.1) and the mobile station has to be 
attached (see clause 5.3). 

7.2.3 E-Mail {Download|Upload} Setup Time [s] 
7.2.3.1 Abstract Definition 

The setup time describes the time period needed to access the service successfully, from starting the dial-up connection 
to the point of time when the content is sent or received. 



7.2.3.2 Abstract Equation 



E - Mail {Download I Upload} Setup Time [s] = (t 



service access successful service access start 



t)[s] 



£75/ 



157 



ETSI TS 102 250-2 VI .5.1 (2007-10) 



7.2.3.3 Trigger Points 

Download: 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


Wrvice access start: Time of service 
access attempt 


Start: Customer initiates the 
service access. 


Start: AID command. 


^service access successful ■ "^® ° 
successful service access 


Stop: First content is received. 


Stop IVIethod A: Reception of the first data 
pacl<et containing content. 

Stop IVIethod B: Send RETR command. 



Upload: 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


Wrvice access start: Time of service 
access attempt 


Start: Customer initiates the 
service access. 


Start: AID command. 


^service access successful ■ "^® ° 
successful service access 


Stop: First content is sent. 


Stop Method A: Sending of the first data packet 
containing content. 

Stop Method B: Reception of the positive 
acknowledgement (250) for the HELO 
command which was sent from the client 
before. This definition applies to the "none login 
procedure", for other login procedures the 
trigger point has to be defined. 



Remark: 

• The PS bearer has to be active in the cell used by a subscriber (see clause 5.1) and the mobile station has to be 
attached (see clause 5.3). 

7.2.4 E-Mail {Download| Upload} IP-Service Access Failure Ratio [%] 
7.2.4.1 Abstract Definition 

The IP-service access ratio denotes the probability that a subscriber cannot establish an TCP/IP connection to the server 
of a service successfully. 



7.2.4.2 Abstract Equation 



E - Mail {Download I Upload} IP - Service Access Failure Ratio [%] = 

unsuccessful attempts to establish an IP connection to the server 
all attempts to establish an IP connection to the server 



xlOO% 
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7.2.4.3 Trigger Points 

Download: 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


IP-Service access attempt 


Start: Customer initiates e-IVIail 
download. 


Start: First [SYN] sent. 


Successful attempt 


Stop: E-Mail download starts. 


Stop IVIethod A: Reception of the first data 
packet containing content. 

Stop IVIethod B: Send RETR command. 


Unsuccessful attempt 


Stop trigger point not reached. 



Upload: 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


IP-Service access attempt 


Start: Customer initiates e-Mail 
upload. 


Start: First [SYN] sent. 


Successful attempt 


Stop: E-Mail upload starts. 


Stop Method A: Sending of the first data packet 
containing content. 

Stop Method B: Reception of the positive 
acknowledgement (250) for the HELO 
command which was sent from the client 
before. This definition applies to the "none login 
procedure", for other login procedures the 
trigger point has to be defined. 


Unsuccessful attempt 


Stop trigger point not reached. 



Remark: 

• The PS bearer has to be active in the cell used by a subscriber (see clause 5.1) and the mobile station has to be 
attached (see clause 5.3) as well as the respective PDP context has to be activated (see clause 5.5). 

7.2.5 E-Mail {Download| Upload} IP-Service Setup Time [s] 
7.2.5.1 Abstract Definition 

The IP-service setup time is the time period needed to establish an TCP/IP connection to the server of a service, from 
sending the initial query to a server to the point of time when the content is sent or received. 



7.2.5.2 Abstract Equation 



E - Mail {Download I Upload} IP - ServiceSetup Time [s] = 



(t 



IP-Service access successful IP-Service access start 



t)[s] 
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7.2.5.3 Trigger Points 

Download: 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


V-Service access start ■ "'"''^^ °^ "^" 
Service access attempt 


Start: Customer initiates e-IVIail 
download. 


Start: First [SYN] sent. 


V-Service access successful ■ '^™^ °^ 
successful IP-Service access 


Stop: E-Mail download starts. 


Stop Method A: Reception of the first data 
packet containing content. 

Stop Method B: Send RETR command. 



Upload: 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


V-Service access start ■ ^ime of IP- 
Service access attempt 


Start: Customer initiates e-Mail 
upload. 


Start: First [SYN] sent. 


V-Service access successful ■ "'"''^^ °^ 
successful IP-Service access 


Stop: E-Mail upload starts. 


Stop Method A: Sending of the first data packet 
containing content. 

Stop Method B: Reception of the positive 
acknowledgement (250) for the HELO 
command which was sent from the client 
before. This definition applies to the "none login 
procedure", for other login procedures the 
trigger point has to be defined. 



Remark: 

• The PS bearer has to be active in the cell used by a subscriber (see clause 5.1) and the mobile station has to be 
attached (see clause 5.3) as well as the respective PDP context has to be activated (cf-PDP Context Activation 
Failure Ratio). 

7.2.6 E-Mail {Download | Upload} Session Failure Ratio [%] 
7.2.6.1 Abstract Definition 

The completed session ratio is the proportion of uncompleted sessions and sessions that were started successfully. 



7.2.6.2 Abstract Equation 



E - Mail {Download I Upload} Session Failure Ratio [%] : 



uncompleted sessions 
successfully started sessions 



-xlOO% 
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7.2.6.3 Trigger Points 

Download: 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


Successfully started session 


Start: Customer initiates e-IVIail 
download. 


Start: First [SYN] sent. 


Completed session 


Stop: E-IVIail download successfully 
completed. 


Stop IVIethod A: Reception of the last data 
packet containing content. 

Stop IVIethod B: Reception of the last data 
packet containing the finish sequence 
(CRLF.CRLF). 


Uncompleted session 


Stop trigger point not reached. 



Upload: 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


Successfully started session 


Start: Customer initiates e-IVIail 
upload. 


Start: First [SYN] sent. 


Completed session 


Stop: E-IVIail upload successfully 
completed. 


Stop IVIethod A: Reception of the [FIN, ACK] for 
the last data packet containing content. 

Stop Method B: Reception of the positive 
acknowledgement (250) for the EOlVI command. 


Uncompleted session 


Stop trigger point not reached. 



Remark: 



The PS bearer has to be active in the cell used by a subscriber (see clause 5.1) and the mobile station has to be 
attached (see clause 5.3) as well as the respective PDP context has to be activated (see clause 5.5). 



7.2.7 



E-Mail {DownloadI Upload} Session Time [s] 



7.2.7.1 Abstract Definition 

The session time is the time period needed to successfully complete a PS data session. 

7.2.7.2 Abstract Equation 



E- Mail {DownloadI Upload}Session Time [s] = (t,. 



session end session start 



t. 



:)[S] 



7.2.7.3 Trigger Points 

Download: 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


Wssion start: Time of successfully 
started session 


Start: Customer initiates e-IVIail 
download. 


Start: First [SYN] sent. 


Wssion end : Time when session 
completed 


Stop: E-IVIail download successfully 
completed. 


Stop Method A: Reception of the last data 
packet containing content. 

Stop Method B: Reception of the last data 
packet containing the finish sequence 
(CRLF.CRLF). 
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Upload: 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


Wssion start: Time of successfully 
started session 


Start: Customer initiates e-Mail 
upload. 


Start: First [SYN] sent. 


Wssion end : Time when session 
completed 


Stop: E-Mail upload successfully 
completed. 


Stop Method A: Reception of the [FIN, ACK] for 
the last data packet containing content. 

Stop Method B: Reception of the positive 
acknowledgement (250) for the EOM command. 



Remark: 

• The PS bearer has to be active in the cell used by a subscriber (see clause 5.1) and the mobile station has to be 
attached (see clause 5.3) as well as the respective PDP context has to be activated (see clause 5.5). 

7.2.8 E-Mail {Download | Upload} Mean Data Rate [kbit/s] 
7.2.8.1 Abstract Definition 

After a data link has been successfully established, this parameter describes the average data transfer rate measured 
throughout the entire connect time to the service. The data transfer shall be successfully terminated. The prerequisite for 
this parameter is network and service access. 



7.2.8.2 Abstract Equation 



E - Mail { Download I Upload } Mean Data Rate [kbit/s] = 
user data transferred [kbit] 



data transfer complete data transfer start 



JSi 



7.2.8.3 Trigger Points 

The average throughput is measured from opening the data connection to the end of the successful transfer of the 
content (file, e-mail or web page). 

Download: 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


*data transfer start ■ Time of 
successfully started data transfer 


Start: E-Mail download starts. 


Start Method A: Reception of the first data 
packet containing content. 

Start Method B: Send RETR command. 


Wta transfer complete : Time when 
data transfer complete 


Stop: E-Mail download successfully 
completed. 


Stop Method A: Reception of the last data 
packet containing content. 

Stop Method B: Reception of the data packet 
containing the finish sequence (CRLF.CRLF). 
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Upload: 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


Wta transfer start : Time of 
successfully started data transfer 


Start: E-Mail upload starts. 


Start Method A: Sending of the first data packet 
containing content. 

Start Method B: Reception of the positive 
acknowledgement (250) for the HELO 
command which was sent from the client 
before. This definition applies to the "none login 
procedure", for other login procedures the 
trigger point has to be defined. 


Wta transfer complete : Time when 
data transfer complete 


Stop: E-Mail upload successfully 
completed. 


Stop Method A: Reception of the [FIN, ACK] for 
the last data packet containing content. 

Stop Method B: Reception of the positive 
acknowledgement (250) for the EOM command. 



Remark: 

• The mobile station is already attached (see clause 5.3), a PDP context is activated (see clause 5.5) and a 
service was accessed successfully (see Service Non-Accessibility). 

7.2.9 E-Mail {Download | Upload} Data Transfer Cut-off Ratio [%] 
7.2.9.1 Abstract Definition 

The data transfer cut-off ratio is the proportion of incomplete data transfers and data transfers that were started 
successfully. 



7.2.9.2 Abstract Equation 



E - Mail {Download I Upload} Data Transfer Cut - off Ratio [%] : 
incomplete data transfers 



successfully started data transfers 



-xlOO% 



7.2.9.3 Trigger Points 

Download: 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


Successfully started data transfer 


Start: E-Mail download starts. 


Start Method A: Reception of the first data 
packet containing content. 

Start Method B: Send RETR command. 


Complete data transfer 


Stop: E-Mail download successfully 
completed. 


Stop Method A: Reception of the last data 
packet containing content. 

Stop Method B: Reception of the data packet 
containing the finish sequence (CRLF.CRLF). 


Incomplete data transfer 


Stop trigger point not reached. 
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Upload: 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description / protocol part 


Successfully started data transfer 


Start: E-Mail upload starts. 


Start Method A: Sending of the first data packet 
containing content. 

Start Method B: Reception of the positive 
acknowledgement (250) for the HELO 
command which was sent from the client 
before. This definition applies to the "none login 
procedure", for other login procedures the 
trigger point has to be defined. 


Complete data transfer 


Stop: E-Mail upload successfully 
completed. 


Stop Method A: Reception of the [FIN, ACK] for 
the last data packet containing content. 

Stop Method B: Reception of the positive 
acknowledgement (250) for the EOM command. 


Incomplete data transfer 


Stop trigger point not reached. 



Remark: 

• The mobile station is already attached (see clause 5.3), a PDP context is activated (see clause 5.5) and a 
service was accessed successfully (see Service Non-Accessibility). 

7.3 Multimedia IVIessaging Service (MIVIS) 

NOTE: It is important to keep in mind that measurement equipment and techniques used can affect the data 

collected. The measurement equipment and techniques should be defined and their effects documented 
for all tests. One example of this is the effect of Windows RAS on the setup of PDP Context 

(see TS 102 250-3 [5]). 
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7.3.1 



Parameter Overview Chart 



^-party 
side 



MMS Send Failure Ratio 
^ MMS Send Time ^ 



parameters 



trigger points 

customer's 

view 



technical 

trigger points 

for success 

cases 



Pusti "Send" 
message button at 
A-party side 



First data packet is 
uploaded by the A- 
party side 

t1 



See start of 
message upload at 
A-party side 



Upload of the first 
data packet 
containing content. 

t2 



See end of 
message upload ; 
A-party side 



Reception of final j 

acknowledgemenq 

for the last data 

packet containing | 

content 

t3 



trigger points 
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view I 



Notification 
download starts 




B-party 
side 




t5 

Reception of the 

first data packet 

containing 

notification content 



See first incoming 
notification data at 
B-party side 
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received 
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received at B-parw 
side ■ 



^ MMS 



Notification Failure Ratio 



MS Notification Time 



latio Jf 



Client requests the 
message 



Start further 
message download 
at B-party side 



t8 

Reception of the 
first data packet 
containing message 
content 



See incoming 
message data at B- 
party side 



MMS Retrieval Failure Ratio 



IVIMS Retrieval Time 



19 

Message is I 
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side 
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MMS End to End Failure Ratio 



MMS End to End Delivery Time 



J 



Figure 41 : MMS Parameter Overview with Trigger Points 
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7.3.2 MMS Send Failure Ratio [%] 
7.3.2.1 Abstract Definition 

The parameter MMS Send Failure Ratio describes the probabiUty that a MMS -message can not be send by the 
subscriber, ahhough he has requested to do so by pushing the "send button". 



7.3.2.2 Abstract Equation 



, „,^^ . ^ ., ^ . n^n unsuccessful MMS send attempts ,„„^ 

MMS Send Failure Ratio [%] = ^^x 100 % 

all MMS send attempts 



7.3.2.3 Trigger Points 



Event from abstract 
equation 


Trigger point from 
customer's point of view 


Technical description / protocol part 


MMS Send Attempt 


Pushing of send button. 


The send button initiates the PDP context activation of the 
MS (MO), followed by a connection to the WAP Gateway, 
and to the MMSC. (See trigger 1 in figure 42). 


Unsuccessful MMS Send 
Attempt 


Do not see "Message 
sent". 


The m-send.conf {see [2]) (where Response 

Status: $80 = M_RS_OK) is not received by the MS(MO). 

(See trigger 18 in figure 42). 

(see notes 1 to 3). 

"MMS unsuccessful send attempt timeout" as specified in 

TS 102 250-5 [25]. 


NOTE 1 : The phase where the WAP session will be deactivated is not covered by this indicator. Some mobiles 
might not support the sending/receiving of the next MMS unless the WAP session is disconnected 
properly. 

NOTE 2: A forwarding of a MMS without reception of a positive m-send.conf (where Response Status: $80 = 
M_RS_OK) shall be counted as failure. 

NOTE 3: Only MMS sent within the timeouts will be considered. 
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MMS Transmission Signalling Diagram 

The diagram shows the transmission of a MS from MO to 
MT, the diagram is layer comprehensive 



MO 



--activate pdp context REQUEST- 

-activate pdp context ACCEPT 

wsp connect REQUEST 

wsp connect REPLY 

wtpACK 

MMS m-send.req 

WtpACK 



—MMS m-send.req >» 

-MMS m-send.conf o 

WtpACK >» 

-wsp DISCONNECT >» 



~wtp ACK~ 



25 

o MMS m-notification.ind — 

<« activate pdp context REOUEST- 

activate pdp context ACCEPT 

<« wsp connect REQUEST — 



■—wsp connect REPLY 

WtpACK ■ 

-WSP/HTTP Get REQUEST- 



wtp ack 

m-retrieve.conf — 

«< WtpACK 

m, retrieve, conf— 

<« m-notifyResp.ind- 

o WtpACK 



<«— 



-wsp DiSCONNECT- 



Figure 42: MMS Transaction flow (immediate retrieval) 
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7.3.3 MMS Retrieval Failure Ratio [%] 
7.3.3.1 Abstract Definition 

The parameter MMS Retrieval Failure Ratio describes the probability that the MMS-message can not be downloaded by 
the MT mobile, which received a MMS notification before. 



Remark: 



The MMS notification is a push-message. This message either initiates the download of the MMS content by 
starting a "WAP Get Request" (when the mobile is switched to automatic mode) or enables the user to 
manually start this "Wap Get Request" (when the mobile is switched to manual mode). The measurements will 
be done either using the setting "Automatic Download" (e.g. the download follows the immediate retrieval 
transaction flow) or following the delayed retrieval. In case of delayed retrieval the wait time between the 
notification response (m-notifyResp.ind) and the WSP/HTTP get request (WSP/HTTP Get.req) must be set to 
zero. Please refer to figure 5 in [2] for the delayed retrieval transaction flow. 



7.3.3.2 Abstract Equation 



MMS Delivery Failure Ratio [% 



unsuccessfiil MMS delivery attempts , „„ „ 

^^xlOO% 

all MMS delivery attempts 



7.3.3.3 Trigger Points 



Event from abstract 
equation 


Trigger point from 
customer's point of view 


Technical description / protocol part 


MMS Retrieval Attempt 
(MT) 


Start; Initiation of the 
Wap Get Request MT. 


Start: After the m-Notification.ind. (see [2]) has been sent 
to the MS (MT), this mobile activates a PDP-context and 
contacts the MMSC via the WAP Gateway (See 
trigger 29 in figure 42). 


Unsuccessful MMS 
Retrieval Attempt (MT) 


Stop: No MMS-message is 
received. 


Stop: The m-notifyResp.ind (see [2]) is not sent by the 

MS (MT). (See trigger 49 in figure 42). 

(see notes 1 and 2). 

"MMS unsuccessful Retrieval timeout" as specified in 

TS 102 250-5 [25]. 


NOTE 1 : The phase where the WAP session will be deactivated is not covered by this indicator. Some mobiles 
might not support the sending/receiving of the next MMS unless the WAP session is disconnected 
properly. 

NOTE 2: Only MMS received within the timeouts will be considered. 



7.3.4 MMS Send Time [s] 
7.3.4.1 Abstract Definition 

A subscriber uses the Multimedia Messaging Service (as indicated by the network ID in his mobile phone display). The 
time elapsing from pushing the send button after the editing of a MMS-message to the completion of the data transfer is 
described by this parameter. 

NOTE: Possible measurement scenarios for time indicators of MMS may vary in the number of involved 
MMSCs. With increasing MMS-traffic or internetwork-traffic surveillance, the number of MMSCs 
involved will increase also. Number of MMSCs involved is therefore a measurement condition to be 
discussed. 



7.3.4.2 Abstract Equation 



MMS Send Time [s] = (t^^M>,,„^™Qn^^„,»,» - 1. 



'-MMStoMMSCoomplete "-sendButton 



)[S] 
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7.3.4.3 Trigger Points 



Event from abstract 
equation 


Trigger point from 
customer's point of view 


Teclinical description / protocol part 


'sendButton 


Start: Send button is pushed. 


Start: The send button initiates the PDP context activation 

of the MS(MT), followed by a connection to the WAP 

Gateway 

(See trigger 1 in figure 42). 

(see notes 1 and 2). 

"MMS unsuccessful send transfer timeout" as specified in 

TS 102 250-5 [25]. 


*MMStoMMSCcomplete 


Stop: MMS-message is 
completely transmitted to 
MMS-C. 


Stop: The m-send.conf {see [2]) (where Response 
Status: $80 = M_RS_OK) is not received by the MS(MO). 
(see trigger 18 in figure 42). 


NOTE 1 : The phase, where the WAP session will be deactivated is not covered by this indicator. Some mobiles 
might not support the sending/receiving of the next MMS unless the WAP session is disconnected 
properly. 

NOTE 2: Only MMS send within the timeouts will be considered. 



7.3.5 MMS Retrieval Time [s] 

7.3.5.1 Abstract Definition 

The reception of a MMS-message works as follows: A push-sms is sent to the receiver's mobile. In automatic mode, the 
push sms initiates a WAP -connection to download the MMS from the MMS-C. The initiation of the WAP connection is 
called the WAP GET REQUEST (WGR). The time elapsing between the WGR and the completion of the download of 
the MMS will be described by the parameter MMS Retrieval Time. 

Possible measurement scenarios for time indicators of MMS may vary in the number of involved MMSCs. With 
increasing MMS-traffic or internetwork-traffic surveillance, the number of MMSCs involved will increase also. 
Number of MMSCs involved is therefore a measurement condition to be discussed. 

7.3.5.2 Abstract Equation 



MMS Delivery Time [s] = (t 



MMSfromMMSCcomplete ^initWGR 



)[S] 



7.3.5.3 Trigger Points 



Event from abstract 
equation 


Trigger point from 
customer's point of view 


Tecfinical description / protocol part 


^initWGR 


Start: Time when WAP Get 
Request is initiated. 


Start: The m-Notification.ind (see [2] is delivered to the 
MS (MT). This initiates the PDP context activation. 
(See trigger 29 in figure 42). 


^MMSfromMMSCcomplete 


Stop: MMS-message is 
received completely. 


Stop: The m-notifyResp.Ind (see [2]) is sent by the MS 

(MT). (See trigger 49 in figure 42). 

(see notes 1 and 2) 

"MMS successful retrieval timeout" as specified in 

TS 102 250-5 [251. 


NOTE 1 : The phase, where the WAP session will be deactivated is not covered by this indicator. Some mobiles 
might not support the sending/receiving of the next MMS unless the WAP session is disconnected 
properly. 

NOTE 2: Only MMS received within the timeouts will be considered. 
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7.3.6 MMS Notification Failure Ratio [%] 
7.3.6.1 Abstract Definition 

The parameter MMS Notification Failure Ratio [%] describes the probability that the Multimedia Messaging 
Service (MMS) is not able to deliver the Notification of a MMS-message to the b-parties mobile. 



7.3.6.2 Abstract Equation 



MMS Notification Failure Ratio [%] ■■ 



failed MMS - notifications 
successfufly submitted MMS 



xlOO% 



7.3.6.3 Trigger Points 



Event from abstract 
equation 


Trigger point from 
customer's point of view 


Technical description / protocol part 


Successfully submitted 
MMS MO 


Start: Reception of the 
acknowledgement from 
the MMS-C MO 
(i.e. "Message sent"). 


Start: The m-send.conf {see [2]) (where Response 
Status: $80 = M_RS_OK) is not received by the MS(MO). 
(See trigger 1 8 in figure 42). 
(see notes 1 and 2) 


Failed MMS-Notifications 


Stop: Failure delivery 
(non-delivery) of the 
Notification-SMS. 


Stop: m- notification. ind (see [2]) is not delivered to the 

MS(MT). 

(See trigger 28 in figure 42). 

(see note 3) 

"MMS successful notification timeout" as specified in 

TS 102 250-5 [25]. 


NOTE 1 : The phase where the WAP session will be deactivated is not covered by this indicator. Some mobiles 
might not support the sending/receiving of the next MMS unless the WAP session is disconnected 
properly. 

NOTE 2: Only the accepted MMS has to be considered (see the response status = $80 in the sendconf) 
MMS with negative response but delivered can added alternatively. 

NOTE 3: Only Notifications received within the timeouts will be considered as successful. 



7.3.7 



MMS Notification Time [s] 



7.3.7.1 



Abstract Definition 



A subscriber uses the Multimedia Messaging Service. The time elapsing from the complete submission of the 
Multimedia-Message to the MMSC to the reception of the Notification (MT) is the MMS Notification Delay. 

Possible measurement scenarios for time indicators of MMS may vary in the number of involved MMSCs. With 
increasing MMS-traffic or internetwork-traffic surveillance, the number of MMSCs involved will increase also. 
Number of MMSCs involved is therefore a measurement condition to be discussed. 



7.3.7.2 Abstract Equation 



MMS Notification Time [s] = (t 



recNotif ^MMSsubmit 



)[S] 
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7.3.7.3 Trigger Points 



Event from abstract 
equation 


Trigger point from 
customer's point of view 


Teclinical description / protocol part 


^MMSsubmit 


Start: The MMS is 
submitted successfully. 


Start: The m-send.conf {see [2]), (where Response 
Status: $80 = M_RS_OK) is not received by the MS(MO). 
(See trigger 18 in figure 42). 
(see notes 1 and 2). 


^recNotif 


Stop: Time when the 
notification is received 
(MT). 


Stop: m-Notif.ind (see [2]) is received by MS (MT) 

(See trigger 28 in figure 42). 

(see note 3). 

"MMS successful notification timeout" as specified in 

TS 102 250-5 [25]. 


NOTE 1 : The phase, where the WAP session will be deactivated is not covered by this indicator. Some mobiles 

might not support the sending/receiving of the next MMS unless the WAP session is disconnected 

properly. 
NOTE 2: The phase, where the WAP session will be deactivated is not covered by this indicator. Some mobiles 

might not support the sending/receiving of the next MMS unless the WAP session is disconnected 

properly. 
NOTE 3: Only Notifications received within the timeouts will be considered as successful. 



7.3.8 MMS End-to-End Failure Ratio [%] 

7.3.8.1 Abstract Definition 

The parameter MMS end-to-end failure ratio describes the probabihty that the Multimedia Messaging Service (MMS) is 
not able to deliver a MMS-message after the "send button" has been pushed or the MO party has not received an 
acknowledgement of the successful transmission from the MMSC. 

7.3.8.2 Abstract Equation 



MMS End - to - End Failure Ratio [%] ■■ 



unsuccessiiilly delivered MMS - messages 
all MMS send attempts 



xlOO% 



End-to-end parameter measurement may optionally be derived by concatenating the component measurements. 

7.3.8.3 Trigger Points 



Event from abstract 
equation 


Trigger point from 
customer's point of view 


Technical description / protocol part 


MMS Send Attempt by 
MS(MO) 


Start: Pushing of send 
button. 


Start: The send button initiates the PDF context activation 
of the MS, followed by a connection to the WAP Gateway. 
(See trigger 1 in figure 42). 
(see note 1). 


Unsuccessful MMS 
Retrieval Attempt of 
MS(MT) 


Stop: No MMS-message is 
received (MT) or no 
acl<nowledgement from the 
MMSC is received at MS 
(MO). 


Stop: The m-send.conf (where Response 

Status: $80 = M_RS_OK) is not received by the MS(MO). 

(See trigger 18 in figure 42) or the m-notifyResp. ind 

(see [2]) (see is not sent by the MS (MT)). 

(See trigger 18 and 49 in figure 42). 

(see notes 2 and 3). 

MMS unsuccessful End-to-End timeout as specified in 

TS 102 250-5 [25]. 


NOTE 1 : The forwarding of a MMS by the MMSC to the MS (MT) might be possible without the reception of the 
m-send.conf MS (MO) (see [2]), (where response status is $80 = M RS OK). 

NOTE 2: The phase where the WAP session will be deactivated is not covered by this indicator. Some mobiles 
might not support the sending/receiving of the next MMS unless the WAP session is disconnected 
properly. 

NOTE 3: Only MMS received within the timeouts will be considered. 
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7.3.9 MMS End-to-End Delivery Time [s] 

7.3.9.1 Abstract Definition 

A subscriber uses the Multimedia Messaging Service (as indicated by the network ID in his mobile phone display). The 
time elapsing from pushing of the "send button" to the reception of the MMS by the b-parties mobile is the MMS 
End-to-end Delivery Time. 

This parameter is not calculated if the MO party has not received an acknowledgement of the successful transmission 
from the MMSC. 

The size of a MMS varies. In comparison to SMS, the size has noticeable impact on the submission time. So, a typical 
sized MM is used for this measurement. See Auxiliary (Network Performance-) Parameter "MMS Average Size". 

NOTE 1 : Possible measurement scenarios for time indicators of MMS may vary in the number of involved 
MMSCs. With increasing MMS-traffic or internetwork-traffic surveillance, the number of MMSCs 
involved will increase also. Number of MMSCs involved is therefore a measurement condition to be 

discussed. 

NOTE 2: End-to-end parameter measurement may optionally be derived by concatenating the component 
measurements. 

7.3.9.2 Abstract Equation 



MMS End - to - End Delivery Time [s] = (t 



MMSrec ~ *• sendAttempt 



)[S] 



7.3.9.3 Trigger Points 



Event from abstract 
equation 


Trigger point from 
customer's point of view 


Technical description / protocol part 


^sendAttempt 


Start: Time when the "send 
button" is pushed. 


Start: The send button initiates the PDP context activation 

of the MS (MO), followed by a connection to the WAP 

Gateway. 

(See trigger 1 in figure 42). 

(see note 1). 


^MMSrec 


Stop: Time when the MMS is 
received at the b-parties 
mobile. 


Stop: The M-resp.ind (see [2]) is received completely by 

the MS (MT), and the MS (MT) sends the m-notify-resp.ind 

(See trigger 49 in figure 42). 

(see notes 2 to 4). 

"MMS successful End-to-end timeout" as specified in 

TS 102 250-5 [25]. 


NOTE 1 : The forwarding of a MMS by the MMSC to the MS (MI) might be possible without the reception of the 

m-send.conf MS (MO). 
NOTE 2: Parameter not calculated if the m-send.conf (where Response Status: $80 = M_RS_OK) is not received 

by MS (MO) (See trigger 18 in figure 42). 
NOTE 3: The phase where the WAP session will be deactivated is not covered by this indicator. Some mobiles 

might not support the sending/receiving of the next MMS unless the WAP session is disconnected 

properly. 
NOTE 4: Only MMS received within the timeouts will be considered. 
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7.4 Short Message Service (SMS) 



7.4.1 Parameter Overview Cinart 



A-party 
side 



B-party 
side 



parameters 




parameters 




SMS Service Non Accessibility MO 



less Delay MO 



Pusii "Send" ^^" 
message button at 
A-party side 



First data packet is 
uploaded by the A- 
party side 



tl 



message upload at 
A-party side 




Upload of ttie first 
data packet 
containing content. 



t2 



message uploaq 
A-party side 



Reception of final 
acknowledgement 
for tfie last data 
packet containing 
content _^^^H 
13 




lotification 
download starts *1) 



See start of 
notification 



t5 

Reception of^^H 

first data packet 

containing 

notification content 

nj 



See first incoming 
notification data at 



Notification is 
received *1) 



See notification is 
received at B-party 



F 



Client requests ttie 
message 



Start further 
message download 
at B-party side 



18 

Reception of the 
first data packet 
containing message 
content 



See incoming 
message data at B- 
party side 



19 

Message is ^^n 
received completely 
at B-party side 



See complete 
message at B-party 



f 



SMS Completion Failure Ratio 



SMS End to End Delivery Time 



*1) For the SMS service a paging is proceed within the notification phase. 

Figure 43: SMS Parameter Overview with Trigger Points 
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7.4.2 SMS Service Non-Accessibility MO [%] 
7.4.2.1 Abstract Definition 

Probability that the end-customer cannot access the Short Message Service when requested while it is offered by display 
of the network indicator on the Mobile Equipment. 



7.4.2.2 Abstract Equation 

NOTE: For the trigger point explained here, the connection over the air interface must be tested (e.g. Layer-3). 
Only the first try should be measured. If the Short Message is established with the second try, it shall not be counted. 



SMS Service Non - Accessibility MO [%] 



unsuccessilil SMS service attempts 
all SMS service attempts 



xlOO% 



7.4.2.3 Trigger Points 



Event from abstract 
equation 


Trigger point from customer's point 
of view 


Technical description / protocol part 


SMS service attempt 


Start: Push send button (initiate 
sending a SMS). 


Stop: The "Access request" is sent by the MS (MO) 

(yellow point in figure 27). 

Detailed: CM Service Request is sent from MO. 


Successful SMS 
service attempt 


Stop: Receive the acknowledgement 
from the SMSC in the MO-party. 


Stop: "Delivery report" is received in the MS (MO) 

(green point in figure 27). 

Detailed: CP DATA (RP ACK) is received by MO. 


Unsuccessful SMS 
service attempt 


Stop trigger point not reached. 



Remark: 



The defined technical description / protocol part trigger points are on the lowest protocol layer. If this layer is 
not available, e.g. because the measurement equipment does not provide this layer, then upper protocol layer 
events can be used to measure the SMS service non-accessibility. The chosen trigger points must be as close as 
possible to the lower layer events. 

If the mobile fulfils TS 127 005 [24] then the following method (via AT interface) can be used for measuring 
the SMS service non-accessibility: 

Start trigger: ATh-CMGS = <len> or <MSISDN> (parameter depends on the H-CMGF setting, PDU or 
text mode) ordered via the AT interface; 

Stop trigger: Any answer received from the mobile or timeout occurred. OK answer handled as a positive 
answer, any other as a negative one. 
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EHS-iimsc 



10 a. IDessag^e 



transfer 



10b. Delivery 



report 



9 . forwar dShortHessage 



3h. Delivery report 



HSC or S&SN 



Access request I 

< >A 

and possible T 

aut hfi nt i c at i on 



7a. Message transfer 



8a. sendlnf oFor- 
< > 

HO-SHS Z) 



7b. Delivery report 



J? 



Operation invocation or message transfer 

Successful operation invocation or message transfer including report 



NOTE 1 : Described in TS 1 24 008 [1 0] and TS 1 29 002 [1 2]. 
NOTE 2: This operation is not used by the SGSN. 

Figure 44: SMS Transaction flow - lUlO 

7.4.3 SMS Access Delay MO [s] 
7.4.3.1 Abstract Definition 

Time between sending a Short Message to a Short Message Centre (SMSC) and receiving the notification from the 
Short Message Centre. 



7.4.3.2 Abstract Equation 



SMS Access Delay MO [s] = (t 



receive sendSMS 



J[s] 



'^receive- Time when the mobile equipment receives the confirmation from the SMS Centre. 
'•sendSMS- Time when the customer sends his SMS to the SMS Centre. 
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7.4.3.3 Trigger Points 



Event from abstract 
equation 


Trigger point from customer's point 
of view 


Technical description / protocol part 


*sendSMS 


Start: Push send button (initiate 
sending a SMS). 


Start: The "Access request" is sent by the IVIS (IVIO) 

(yellow point in figure 27). 

Detailed: CIV! Service Request is sent from MO. 


'receive 


Stop: Acl<nowledgement from the 
SIVISC is received in IVIO-party. 


Stop: "Delivery report" is received in the MS (MO) 

(green point in figure 27). 

Detailed: CP_DATA (RP_ACK) is received by MO. 



Remark: 

• The defined technical description / protocol part trigger points are on the lowest protocol layer. If this layer is 
not available, e.g. because the measurement equipment does not provide this layer, then upper protocol layer 
events can be used to measure the SMS access delay. The chosen trigger points must be as close as possible to 
the lower layer events. 

If the mobile fulfils TS 127 005 [24] then the following method (via AT interface) can be used for measuring 
the SMS access delay: 

Start trigger: AT+CMGS = <len> or <MSISDN> (parameter depends on the +CMGF setting, PDU or 
text mode) ordered via the AT interface; 

Stop trigger: Any answer received from the mobile or timeout occurred. OK answer handled as a positive 
answer, any other as a negative one. 

7.4.4 SMS Completion Failure Ratio [%] 
7.4.4.1 Abstract Definition 

Ratio of not received and sent test SMS from one mobile to another mobile part, excluding duplicate received and 
corrupted test SMS. 

A corrupted test SMS is a SMS with at least one bit error. 

For test and measurement purposes a message is considered valid if it is delivered successfully within a time window 
defined. 



7.4.4.2 Abstract Equation 



SMS Completion Failure Ratio [%] = 

unsuccessfully received test SMS - duplicate received test SMS - corrupted test SMS 

all sent test SMS 



xlOO% 



7.4.4.3 Trigger Points 



Event from abstract 
equation 


Trigger point from customer's point 
of view 


Technical description / protocol part 


SMS service attempt 


Start: Push send button (Initiate 
sending a SMS). 


Start: The "Access request" is sent by the MS (MO) 

(yellow point in figure 27). 

Detailed: CM Service Request is sent from MO. 


Successfully received 
test SMS 


Stop: The Short Message is received 
by MT-party's mobile. 


Stop: "Message transfer" is received in the MS (MT) 

(green point in figure 28). 

Detailed: CP DATA (RP ACK) is received by MT. 


Unsuccessfully 
received test SMS 


Stop trigger point not reached. 
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Remark: 

• The defined technical description / protocol part trigger points are on the lowest protocol layer. If this layer is 
not available, e.g. because the measurement equipment does not provide this layer, then upper protocol layer 
events can be used to measure the SMS completion failure ratio. The chosen trigger points must be as close as 
possible to the lower layer events. 

If the mobile fulfils TS 127 005 [24] then the following method (via AT interface) can be used for measuring 
the SMS completion failure ratio: 

Start trigger: AT+CMGS = <len> or <MSISDN> (parameter depends on the +CMGF setting, PDU or 
text mode) ordered via the AT interface; 

Stop trigger: CMTI event received on the receiver side (CMGR=<n> gives back the received SMS, or 
CMGL="ALL" or CMGL=4 all of the received ones). In order to receive CMTI events they have to be 
activated at the B-party with the AT+CNMI command. 

The calculation of duplicate or corrupted received SMS is a post processing issue. 

7.4.5 SMS End-to-End Delivery Time [s] 
7.4.5.1 Abstract Definition 

Time between sending a Short Message to a Short Message Centre and receiving the very same Short Message on 
another mobile equipment. 



7.4.5.2 Abstract Equation 



SMS End - to - End Delivery Time [s] = (t 



receiveSMS ''sendSMS 



J[s] 



^receive SMS" Time when the mobile equipment 2 receives the Short Message from mobile equipment 1. 
'■send SMS- Time when the customer sends his Short Message to the SMS Centre. 

7.4.5.3 Trigger Points 

• Start SMS service attempt: Initiate sending a SMS. 

• End SMS service attempt: Receiving SMS on Mobile Equipment 2. 



Event from abstract 
equation 


Trigger point from customer's point 
of view 


Technical description / protocol part 


'sendSMS 


Start: Push send button (Initiate 
sending a SMS). 


Start: The "Access request" is sent by the IVIS (MO) 

(yellow point in figure 27). 

Detailed: CM Service Request is sent from MO. 


receiveSMS 


Stop: Tlie sliort message is received by 
IVIT-party's mobile. 


Stop: "Message transfer" is received in the MS (MI) 

(green point in figure 28). 

Detailed: CP DATA (RP ACK) is received by MT. 



Remark: 



The defined technical description / protocol part trigger points are on the lowest protocol layer. If this layer is 
not available, e.g. because the measurement equipment does not provide this layer, then upper protocol layer 
events can be used to measure the SMS end-to-end delivery time. The chosen trigger points must be as close as 
possible to the lower layer events. 

If the mobile fulfils TS 127 005 [24] then the following method (via AT interface) can be used for measuring 
the SMS end-to-end delivery time: 

Start trigger: ATh-CMGS = <len> or <MSISDN> (parameter depends on the H-CMGF setting, PDU or 
text mode) ordered via the AT interface; 
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Stop trigger: CMTI event received on the receiver side (CMGR=<n> gives back the received SMS, or 
CMGL="ALL" or CMGL=4 all of the received ones). In order to receive CMTI events they have to be 
activated at the B-party with the AT+CNMI command. 

The calculation of duplicate or corrupted received SMS is a post processing issue. 



SC 



SMS-GMSC 



HLR 



1 a. Message 



transfer 



> 



< 



lb. Delivery 



report 



2. SendRoutinglnfo 



<- 



-> 



ForShortMsg 



4a. ForwardShortMessage 



<- 



4b. Delivery report 



3. SM-Delivei 



ReportStatus 



. 



-^ Operation invocation or message transfer. 



IVISC or SGSN 



VLR 



IVIS 



-> 



5. sendlnfoFor- " 



<r 



-> 



<- 



MT-SMS 

6. Message transfer 



^ 



•^ — ^ Successful operation invocation or message transfer including report. 
NOTE: This operation is not used by the SGSN. 

Figure 45: SMS Transaction flow - lUIT 
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Annex A (informative): 

Examples for measuring trigger points 

• SMS-Service: 

Layer 3 Messages: 

■ Start SMS Service Attempt: generating random access (chan_request SDCCH) at mobile 
equipment. 

■ Successful SMS Service Attempt receiving cp_data (rp_ack) at mobile equipment. 

■ Receiving SMS on Mobile Equipment 2: receiving cp_data (rp_ack) at mobile equipment. 
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Annex B (informative): 
Streaming explanations 

RTP - Real Time Protocol: 

The Real Time Protocol is used for the transmission of real-time data, e.g. audio, video, simulation data over multicast 
or unicast network services. No QoS functionality is implemented. 

RTP is designed to be independent from the underlying transport and network layers. For a complete description refer 
to [7]. 

RTCP - Real Time Control Protocol: 

The Real Time Control Protocol as control protocol for the RTP. It allows the monitoring of the data delivery and 
provides a minimal control and identification functionality. RTCP is designed to be independent from the underlying 
transport and network layers. 

For a complete description of the RTCP refer to [7]. 

RTSP - Real Time Streaming Protocol: 

The Real Time Streaming Protocol is used for the overall control of the streaming session. 

For a complete description of the RTSP refer to [8]. 

Most important methods of RTSP: 

• DESCRIBE: The DESCRIBE method retrieves the description of a presentation or media object identified by 
the request URL from a server. It may use the Accept header to specify the description formats that the client 
understands. The server responds with a description of the requested resource. The DESCRIBE reply-response 
pair constitutes the media initialization phase of RTSP [8]. 

SETUP: Causes the server to allocate resources for a stream and start an RTSP session [8]. 

PLAY: Play is send from the client to the server and informs the server to start the transmission of data as 
specified by the SETUP method [8]. 

PAUSE: Send from client to server. Temporarily halts the stream transmission without freeing server 
resources. These resources can only be freed after a specified time [8]. 

RECORD: This method initiates recording a range of media data according to the presentation description [8]. 

TEARDOWN: Frees resources associated with the stream. The RTSP session ceases to exist on the server [8]. 



B.1 Streaming Hyperlink Description 

The following syntax for the hyperlink is used in order to access streaming content on the server: 

protocol://address:port/path/file 



Protocol 


Used protocol. E.g. rtsp:// 


Address 


Address of the used streaming server 


Port 


Port used by the server for answering request 


Path 


Path to the file to be streamed 


File 


The streaming file to be reproduced and its extension 
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Annex C (informative): 

Push to Talk over Cellular Information 

Figures 29 to 32 visualize signal flows of typical PoC Sessions. The figures include the signal flows on the transport 
layer as well as some restricted information on the application layer. To keep the flows concise, some signals are not 
pictured. So it is possible to obtain signal flows universally valid for different kinds of PoC Sessions. Figures 29 to 32 
show particularities using Unconfirmed Indication with Media Buffering as well as differences between Pre-established 
and On-demand PoC Sessions. 
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Figure 46: On-demand PoC Session with manual-answer 
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NOTE: The PoC Server supports Media Buffering and sends tine Tall< Burst confirm message after receiving ttie 
first automatic-answer message. 

Figure 47: Unconfirmed On-demand Ad-lioc PoC Group Session with automatic-answer 
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Figure 48: Confirmed Pre-established session with manual-answer 
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Figure 49: Unconfirmed Pre-established session with automatic-answer 
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C.1 Signal Grouping 



This clause defines groups of signals which will in the following be referred to as building blocks of PoC signal flows, 
or just building blocks. These building blocks are derived from [13], [14], [15], representing only parts of a complete 
signal flow as seen in figures 29 to 32. Here, different building blocks of the same kind correspond to the same QoS 
group. The aim of the definition of such building blocks is to give detailed information on the different signal flows. 

Remark: In the QoS parameter defining clause of the present document, most signal flows shown are less detailed. The 
reason for this is that these flows are only used to visualize the relevant trigger points of the corresponding QoS 
parameter with respect to their occurrence over time. 

The relationship between building blocks and QoS groups is pictured in the following table. In contrast to the signal 
flows given to illustrate QoS parameter definition, only flows leading to a positive result are given. The only exception 
from this is the signal flow for a queued talk burst request which was added for sufficiency. 

A distinction has been made between On-demand and Pre-established PoC Sessions since here different building blocks 
are needed. Crosses are indicating the blocks needed for the corresponding QoS group. For simplicity some crosses are 
greyed. These crosses indicate that a choice between Confirmed and Unconfirmed Indication has to be made. 

Further parameters for the "Session SETUP" are the following: 

• Session SETUP alternative 1: confirmed with auto-answered on terminating side. 

• Session SETUP alternative 2: confirmed with manual answered on terminating side. 

• Session SETUP alternative 3: unconfirmed with auto-answered on terminating side. 



Remark: 



Session SETUP alternative 4: unconfirmed with manual answered on terminating side. 

Only the QoS groups relevant to the building blocks are shown in table 2. 
Building blocks not related to any QoS group are omitted in table 2. 
Building blocks can be identified by their number as specified in table 2. 

Table 2: Assignment of PoC Session parts to building blocks 
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C.2 PoC Service Registration 
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C.4 PoC Session Initiation, Originating Part 

a) PoC On-demand Session Initiation, confirmed 
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b) PoC On-demand Session Initiation, unconfirmed 
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c) PoC Pre-established Session Media Parameters Negotiation 
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d) PoC Pre-established Session Initiation, confirmed 
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e) PoC pre-established Session Initiation, unconfirmed 
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C.5 PoC Session Initiation, Terminating Part 

a) PoC On-demand Session, automatic answer 
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d) PoC Pre-established Session, manual answer 
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C.6 Media Streaming 

a) First Media Stream from User A to PoC Server 
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c) Last Media Stream from User B to User A via PoC Network (without Media Buffering), including Talk Burst 
Request of User B. 
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C.7 Talk Burst Request 



a) Implicit Talk Burst Request (On-demand Session Initiation) 
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C.8 Leaving PoC Session 

a) Leaving On-demand PoC Session 
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b) Leaving Pre-established PoC Session 
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C.9 Deregistration 
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